ETL脚本的版本管理方法和 SourceTree 使用

=============================
使用git管理Kettle 作业的一个注意
=============================
之前 ETL 作业是用 svn 管理的, 迁移到 git 管理也算是大势所趋吧. 这里重点讲一个git管理kettle作业的注意事项:

kettle 既支持基于数据库的repository也支持基于文件repository, 但我更推荐基于文件的repository, 一来脚本可以做版本管理, 二来可以控制上线流程. 如果使用git来管理kettle的作业文件库, 需要注意的是不要将git repository和kettle repository目录设定到同一层, kettle repository 最好是放在git repository的一个子目录下.
如果放到了同一层, 会有一个很严重的后果, 那就是在kettle设计器的open dialog对话框需要很长时间才能打开. 原因也简单, kettle在展现open dialog前, 先要遍历kettle repository下所有的文件, 如果git repository在同一层, kettle将遍历.git这个隐藏目录, 而这个目录的文件数量非常之多, 遍历自然会非常之慢的.

=============================
生产/开发环境的ETL脚本的版本管理方法
=============================

之前 ETL 作业是用 svn 管理的, 在一个专用的 svn repository 下, 创建了 prod 和 testing 目录, 分别对应的 prod 和 testing 环境下的 ETL 脚本. 客户端使用 tortoisesvn 管理, 本地也有两个目录对应 remote 端的两个目录.
svn 管理下的开发流程为: 先在 testing 目录开发, 然后将代码提交到 svn 远程库的 testing 目录下, 然后将远程 testing 目录发布到测试服务器上进行测试. 测试通过后, 将文件复制到本地的 prod 目录, 在提交到 svn 远程库的 prod 目录, 最后部署到 prod 服务器上. 整个过程简单而且不容易出错.

现在ETL 作业要迁移到 git 下管理, 至少有下面两个方案, 即:
方案 1: 采用 git 的 branch 来管理不同环境的 ETL 脚本. 这个做法和一般的业务系统开发一致.
方案 2: 同一个 git branch 使用不同的目录来管理不同的分支, 优点是:平时操作只要留意所在的目录, 而无需在意git的分支, 毕竟多数ETL开发人员对于git分支管理不太懂, 容易弄错. 
我不推荐第 2 个方案, 原因有: ETL 作业其实不像业务系统开发一样,  业务系统中各个文件相互调用情况很多,多人协作是很平常的事情, 另外, 因为业务需要经常出很多feature/bugfix key版本,  git 分支能有效解决这两个痛点. 对于ETL版本管理, 没有必要采用稍显复杂的分支方法.  注意这里所讲的复杂, 并不是指git和 branch相关命令有多复杂, 而是引入这个方案给将来持续开发和上线.

如果你的项目管理是按照方案 2 进行的, 随便什么 git 客户端都很好用, 都不会弄错. 如果是采用方案 1, 我特别推荐使用 sourcetree 这个软件, 原因有:
1. 可以使用非常醒目的 Tab 页的方式来管理不同的 git 库或分支. 
2. 在每个 tab 页下左边的树形结构中, 当前的分支名称被粗体字显示.

下面是一些 sourcetree 使用技巧:

=============================
sourcetree 免注册使用
=============================
参考: http://blog.csdn.net/qq_25867649/article/details/73163510
sourcetree 2.4.8版本安装后需要注册, 下面是跳过注册的方法,

1. 找到目录：C:\Users\用户\AppData\Local\Atlassian\SourceTree
2. 新建 accounts.json 文件里面输入

[
{
"$id": "",
"$type": "SourceTree.Api.Host.Identity.Model.IdentityAccount, SourceTree.Api.Host.Identity",
"Authenticate": true,
"HostInstance": {
"$id": "",
"$type": "SourceTree.Host.Atlassianaccount.AtlassianAccountInstance, SourceTree.Host.AtlassianAccount",
"Host": {
"$id": "",
"$type": "SourceTree.Host.Atlassianaccount.AtlassianAccountHost, SourceTree.Host.AtlassianAccount",
"Id": "atlassian account"
},
"BaseUrl": "https://id.atlassian.com/"
},
"Credentials": {
"$id": "",
"$type": "SourceTree.Model.BasicAuthCredentials, SourceTree.Api.Account",
"Username": "",
"Email": null
},
"IsDefault": false
}
]

=============================
使用本机多个目录来对应远程 git 的多个分支
=============================
假设项目 A 有 master/prod/testing 三个分支, 我们在本机先建立三个对应的目录.
1. 在界面上新建 tab 页, 然后点击 clone, 输入远程的 git 地址, 输入本机 prod 的目录, 点击"高级选项", 选择远程的 prod 分支 (缺省是 master 分支), 点击确定, git 的 prod 版本就会下载到本机. 同时 sourcetree 主界面上也有一个 prod 的 tab 页.
2. 同样的步骤, 将 testing 分支签出到 master 和 testing 目录
3. 经过上述步骤, sourcetree 就有三个 tab 页, 每个页对应不同的分支, 每个分支对应不同的本地目录.

效果如下:

=============================
SourceTree&Git 部分名词解释
=============================

参考: https://www.jianshu.com/p/be9f0484af9d
克隆 (clone)：从远程仓库 URL 加载创建一个与远程仓库一样的本地仓库
检出 (checkout)：切换不同分支
添加（add)：添加文件到缓存区(stage), 为commit操作做准备.
提交 (commit)：将暂存文件(staged file)上传到本地仓库
推送 (push)：将本地仓库同步至远程仓库，一般推送（push)前先拉取（pull)一次，确保一致
移除（remove)：移除文件至缓存区
贮藏 (stash)：保存工作现场,
重置 (reset)：回到最近添加 (add)/提交 (commit) 状态
抓取 (fetch)：从远程仓库获取信息并同步至本地仓库
拉取 (pull)：从远程仓库获取信息并同步至本地仓库，并且自动执行合并（merge)操作，即 ** pull=fetch+merge **
分支 (branch)：创建/修改/删除分枝
标签 (tag):给项目增添标签
工作流 (Git Flow):团队工作时，每个人创建属于自己的分枝（branch)，确定无误后提交到 master 分枝
终端 (terminal):可以输入 git 命令行

=============================
sourcetree软件的pull按钮和merge按钮
=============================
sourcetree 的pull按钮其实相当于 fetch+merge 或fetch+rebase. 这里的merge 和 merge 按钮有一些小的区别. pull中的merge是将远程仓库最新版本merge到本地work copy. 而 merge 按钮功能更加通用, 可以将不同的分支的任意提交合并到本地work copy.

另外, 一般情况下项目成员各自负责自己的模块或文件, 所以文件版本冲突的可能性很小, 基于这个前提, 在使用sourcetree的pull操作时候, 推荐使用rebase模式, 而不是merge模式. 这样的好处是, 提交历史的graph是一个直线, 而不会有很多分叉.

========================
merge和rebase的区别
========================
合并 (merge)：将多个同名文件合并为一个文件，该文件包含多个同名文件的所有内容，相同内容抵消
变基 (rebase)：和merge命令的目的相同,都是用来合并两个commit. merge合并的思路很简单, 而rebase的合并比较复杂, 假设现在有两个分支, 它们是从很久的一个公共commit后就开始分叉, rebase大致的操作过程是, (1)git先会把本地分支所有的commit都回滚到公共点上,并且把它们临时 保存为补丁(patch), 这些补丁放到".git/rebase"目录中. (2)然后拉取另一个分支,(3)然后再把这些patch逐一提交.
变基的更多说明:
https://blog.csdn.net/hudashi/article/details/7664631

====================================
stage(暂存)和stash(贮藏)的区别
====================================
stage 等同于 Index 区.
stage(暂存)和stash(贮藏)的区别: stage暂存其实就是git add, 现将改动加到暂存区, 然后才能commit. stash贮藏区是另一个概念, 用作工作现场的交换区, 我们可以将手头上未提交的改动, 通过 git stash save命令放到贮藏区中, 然后从远程库pull一个分支完成一些工作, 然后我们可以使用 git stash pop 将贮藏区的工作空间完整恢复回来, 然后继续之前的工作.

========================
如何理解 origin 和 master?
========================
摘自: https://blog.csdn.net/abo8888882006/article/details/12375091
在clone完成之后, git客户端将在本地创建一个.git 隐藏目录,并会自动为你将此远程仓库命名为origin(origin只本地仓库给远程仓库起的一个别名, 该别名保存在.git/config文件中, 而本地仅仅是一个克隆), 并下载其中所有的数据,建立一个指向它的master 分支的指针,我们用(远程仓库名)/(分支名) 这样的形式表示远程分支,所以origin/master指向的是一个remote branch(从那个branch我们clone数据到本地),但你无法在本地更改其数据.

同时,Git 会建立一个属于你自己的本地master 分支,它指向的是你刚刚从remote server传到你本地的副本.随着你不断的改动文件,git add, git commit,master的指向会自动移动,你也可以通过merge（fast forward）来移动master的指向.

========================
如何理解 Fast-forward?
========================
git merge 有个Fast-forward模式,即快进模式. 举例讲解一下它的含义, 假设本地有一个master 分支, 紧接着创建了一个dev 分支, 并在dev 分支上对文件做了修改, 然后我们想把这些修改合并到本地的master分支上. 这期间master分支没有做任何修改, 所以合并其实很简单, 只需要移动master指向到dev, 没有任何文件上的合并操作, 对于这样的合并, 叫做Fast-forward合并.
显然并不是所有的合并都可以使用快进模式, 它不适合两个分支都各自长出叶子的情形. 另外, 快进合并后, 分支血缘上没有dev的痕迹. 如果比较注重分支过程管理, 就不推荐使用快进模式, 参数为 no-ff

参考:
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001375840038939c291467cc7c747b1810aab2fb8863508000
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013760174128707b935b0be6fc4fc6ace66c4f15618f8d000
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001375840202368c74be33fbd884e71b570f2cc3c0d1dcf000

=============================
git cheatsheet 
=============================
下面网站是git的cheatsheet, 直观地展现了git 各个Area和相应的命令.
http://ndpsoftware.com/git-cheatsheet.html