Git workflow 详谈

做为一名工程师， Git 在平常开发中是不可或缺的工具。
这里详细介绍几种比较经常使用的基于 Git 的工做流模型, 以便于团队协做的规范化和效率提高。

中心化工做流

使用过SVN的应该都知道， SVN使用的是集中式管理流程， 若是你刚从SVN 切换到 Git ， 你能够尝试使用中心化工做流的方式。这样，你几乎不须要变动以前的工做方式， 就能够完成平滑的过渡了。 并且在使用过程当中还能够看到 Git 优于 SVN 的地方：
第一，每一个成员均可以在本地拥有一份完整的项目代码仓库，而不仅是一个工做区的副本，任何人均可以在本地执行 add 和 commit ，而不须要考虑远端仓库是否有变动，直到须要的时候再去提交便可。
第二，Git 的工做区、暂存区、引用更新等设计，能够给开发者更多自由来切换当前工做，且不会形成代码丢失。

工做细节

中心化工做流的方式是：在远端（远端能够是服务器端，也能够是本地的任意目录）新建一个仓库，默认是 master 分支，做为惟一的中心仓库。 全部人都 clone 这个仓库做为本地仓库，并在本地仓库进行开发。本地的提交是和远端仓库无关的，等须要的时候再 push 进主仓库的 master 分支便可。

在这种方式下， 远端是惟一肯定的中心仓库， 全部人都要以这个仓库为准。 因此，在提交以前要先 fetch 最新提交，在这些提交之上做出本身的更改(通常咱们使用 rebase来完成)。

若是本地的修改和远端仓库中的变动发生了冲突，那么 Git 会暂停 rebase ，并让你来解决这些冲突。咱们能够很简单的使用 git status 和 git add 等命令完成冲突的合并。 另外, 若是咱们解决不了冲突, 咱们也可使用 git rebase --abort 很容易的退出 rebase 的过程。

这样天天的工做方式就变成了，从中心仓库拉取最新代码， 而后开始一天的工做， 开发完成后，拉取中心仓库的更新， 合并代码后， 再提交至中心仓库， 结束一天的工做。 这样的好处就是不须要变动原先（使用SVN）的工做方式。固然弊端也很明显，你并不知道中心仓库的代码是不是稳定的，或者说并不能肯定当你的代码和中心仓库代码合并后，是不是稳定的，带来的问题就是开发进度和回滚不那么方便控制。

示例

咱们有两位程序员, A 和 B, 两人同时在对一个项目作开发, 而且使用 Git 的中心化工做流方式。

1.建立远端中心仓库

这里咱们有两种方式：

• 借助于已经搭建好的平台 GitHub/GitLab 之类的，点击 create repo 便可。

• 在远端(这里只是为了区别本地仓库，事实上，使用任何一个其余人能够连通的机器均可以,包括本身本地其余目录) 建立一个 裸仓库 ，建立裸仓库和咱们平时建立本地仓库的区别，能够参考我另外一篇文章 Git 本地仓库和裸仓库 。

这里以第二种方式为例：

# --bare 参数必须有
git init --bare /the/repo/path.git

2.全部人都 clone 中心仓库到本地做为本地仓库

git clone /the/repo/path.git

注意仓库地址必须是正确的， 且有权限访问才能 clone 成功。

3.程序员 A 在他的本地仓库进行功能开发并进行发布

通常状况下，咱们经过 git status 看看当前状态，并经过 git add 和 git commit 等命令完成本地仓库的提交。 固然这个提交影响的也只是本地仓库而已，并无对中心仓库产生任何影响，因此咱们既不须要关心别人有什么提交，也不用担忧咱们当前的提交是否对别人形成了影响。当 A 认为本身所开发的功能已经完成， 那他将执行 git push origin master 这样的操做，将本身本地仓库全部不存在于中心仓库的提交都 push 到远端的中心仓库上。

4.程序员 B 在他本地仓库进行功能开发

B 在 clone 中心仓库后所作的操做和 A 同样，在本地仓库进行项目开发，并在本地仓库进行提交，他不须要知道中心仓库发生了什么样的变化。

5.程序员 B 将本身开发的功能并进行发布

B 在确认本身开发的功能已经完成后，想要将本身的代码经过 git push origin master 这样的操做发布至中心仓库，可是却被中心仓库提示他的修改已经和中心仓库有了分叉， 须要他先执行 git pull 之类的操做， 将中心仓库上 A 的提交与 B 本地的提交进行合并才容许他并入中心仓库。因此，他执行了 git pull --rebase origin master 来将中心仓库的修改并入他的本地仓库。使用 --rebase 参数的意义在于 fetch 执行完成后，将把 B 的全部提交移至 master 顶端。

固然这里不使用 --rebase 参数也会成功，只不过是会生成一个合并提交，有些状况下使用 --ff 参数也能够避免产生合并提交。在这里使用 --rebase 只是一个建议操做。

若是 A 和 B 修改的文件没有关联，通常状况下会直接完成合并，若是发生冲突，Git 将会暂停 rebase 的过程，并列出当前冲突的文件，你能够简单的使用 git status 和 git add 等命令进行合并，合并后使用 git rebase --continue 继续 rebase 的过程。或者使用 git rebase --abort 退出 rebase 过程。

在 B 合并完成后，能够执行 git push origin master 将本身开发的功能发布至中心仓库。

至此，基础的中心化工做流方式就介绍完了，可是这里也很容易看出来其中的问题，除了前面说到过的之外，还有就是效率低下，若是不少人都在持续进行提交，那很影响新功能的提交（多人持续性进行提交）。 一个比较容易提高效率的方式就是切换到特性分支工做流的方式。

特性分支工做流

基于特性的分支工做流，能够为每一个特性作隔离，避免对中心仓库主干代码形成影响。

工做细节

顾名思义， 就是根据每一个特性都会开一个新的分支，每一个分支都应该包含着描述性的名称，不管是一我的开发，仍是多人协同，该特性的所有开发工做都在这个分支上进行。待该特性开发完成后， 并入主分支，而后删除分支，代码上线。

这种状况下， 最大的优点在于， 全部的特性开发均可以并行处理。 没必要要像中心化工做流方式， 每一个人的变更均可能引发其余的人的代码合并， 而且全部功能都杂糅在一块儿， 从测试和回滚都会变得很繁琐。 另外的一个好处就是特性分支能够推送到中心仓库，这样也便于单独测试。

这里须要注意的是，特性分支往主分支合并的时机，应该是该特性开发完成，并测试经过，避免对主干代码形成污染。

在进行分支隔离后，咱们发现，咱们当前只处理了开发模式，但并无涵盖一个很完备的产品生命周期， 开发、发布、维护等过程，因此，咱们有了 Gitflow 工做流。

Gitflow 工做流

基于Gitflow 的工做流方式， 这种工做流方式， 主要是管理着新功能开发，发布及维护等模式，根据不一样类型的工做对分支进行定义， 分为 特性分支 ，修复分支，release 分支，开发分支 和 主分支 。

主分支：中心仓库创建后的默认 master 分支（固然使用其余分支也能够，但要保证该分支是受保护的）。主分支随时保持代码是稳定的，而且有明确的版本标签，后续代码回滚等操做都将从主分支进行。

开发分支：中心仓库创建后，从 master 分支切出来，此时与 master 分支保持一致。后续演进中，开发分支随时保持代码最新，但却不必定是线上实际运行的代码。

git checkout -b develop

特性分支：应该从开发分支切出，开发完成后， 再合并进入开发分支， 若是达到了发布标准， 则从开发分支切出 release 分支， 切出来的这个分支，只作该版本内的代码修复， 再也不加入新功能， 这时此分支处于锁定的状态。

修复分支， 用于对线上主分支代码的及时修复， 待修复完成后， 合并进入主分支， 再并入开发分支。 修复分支只能从主分支切出。

发版分支， 通常命名为 release-xxx 这个分支只能从开发分支切出， 最后并入主分支，打上版本号的标签，它也应该并入开发分支，若是中间有其余修复的话。

fork 工做流

fork 分支流和上面介绍的全部工做流都不太同样。它的上游有一个惟一仓库， 全部人都是 fork 这个仓库， 在本身的远端和本身的本地各维护一个仓库，待开发完成后推入本身的远端仓库，并结合 GitHub/GitLab等提交 Pull Request，进入了 review 阶段，待经过后，将会被合并入上游惟一的仓库。这种方式比较适合 GitHub 中的大型开源项目， 对于小团队的内部项目， 这种方式可能未必合适。
并且 fork 工做流， 会占用更多的资源（毕竟每一个人都维护一份远端仓库）。 并且每一个人都看不到其余人的动态，只有当提交 Pull Request 的时候， 才知道每一个人发生了什么。

总结

我我的比较推荐的是 Gitflow 的开发工做流， 这种方式下，一切都是可控的， 每一个分支都有各自独立的功能，目的性很明确， 同时，在作代码回滚之类的操做也是能够直接剔除。 另外， 在这种工做流方式下， 团队中的每一个人都能很轻易的知道其余人在作什么， 作出了什么样的改变， 对于团队协做， 或许更加合适。

固然全部的工做流并不必定能彻底套用， 能够吸收一些规范， 合并入本身的平常工做， 将代码仓库的合做流程标准化和规范化， 这也是一切自动化的基础。

---

能够经过公众号 MoeLove 和我联系