前言

在使用 SVN 的时代，一旦一个文件被锁定，其他人都无法修改的情况时常出现，着实让人头痛。Git 横空出世之后，大家因为它带来的便捷性非常有价值纷纷改为这个：它有一系列非常有意义的功能：回滚与重复修改、强大的分支以及 tag 管理、更清晰的历史修改追踪等等。只是，Git 也是由人来使用的，当单个人使用时，无论怎么折腾都没事，而当多人合作开发的时候，就会有各种各样的问题，比如由于 Git 的灵活性，所带来的分支管理与协作流程的问题。

Git Flow

这是最常见的协作流程，并且它已经有现成的工具支持：git flow，简单来说，就是把分支分为：

  • master：主分支，用于追踪线上生产环境的代码；
  • develop：开发分支，用于追踪开发环境的代码；
  • feature/a-new-feature：特性分支，用于不用人员开发新功能，从 develop 开始，结束后合并至 develop 分支；
  • hotfix/vx.x.1：热修复分支，用于紧急修复上线，从 master 开始，结束后合并至 develop 与 master 分支，并打上 hotfix tag ；
  • release/vx.0.0：预发布分支，从 develop 开始，结束后合并至 develop 与 master 分支，并打上 release tag ；

这个模型还是很有用了，将分支管理规范起来，多人协作很方便。只是，实际使用中，会有一些问题：

  • ** 繁琐 **，尤其是热修复的时候，因此有时候热修复分支会被滥用：上线小功能也会用热修复。另外，有时候开发人员也会犯错：合并代码出错，忘记合并回 develop，刚在本地合并完，发现已经落后于线上的代码；
  • 当团队使用线上 Git 管理工具的时候，就会有点麻烦了：与 Pull/Merge request 以及 Code Review 配合起来不方便，一般我们很鸡肋地让开发人员 feture 分支合并到 develop 的时候，以及 hotfix 分支合并到 master 分支的时候做 Pull/Merge request 以及 Code Review；
  • 与 CI & CD 流程配合起来不方便，当 hotfix 与 release 分支合并回 develop 分支的时候，按照 CI 的理论，你是应该重新 build 的，只是，这样会显得很多余；

Github flow

其实你不妨观察下 Github 上的各种开源项目，就会很容易发现他们使用的流程很简单：只有 master 这个长期存在的分支，以及其他的 feature 分支。所有的 feature 分支都会向 master 分支合并，Code Review 以及 Pull request 在这个过程能很好的结合在一起。

只是，由于太简单，因此有些需求点，它做不到：代码部署的问题，即 master 的代码不代表生产环境的代码，即无法追踪。

Gitlab flow

Gitlab flow 算是这三者里面，最适合使用 gitlab 管理工具的团队使用的流程：它引入了一个概念叫做：Upstream first。

简单来说，它就是在 Github flow 的基础上，分别引入不同的 downstream 分支策略：

生产环境分支策略

对于像手机应用一样的项目，再添加一个 production 分支即可，production 为 master 的 downstream 分支，所有合并到 master 的代码，如果需要发布，则合并到 production，用以追踪，（很明显，手机应用需要提交审核，这时候我们也需要合并代码至 master）；

多环境分支策略

对于使用 CI & CD 的后端项目来说，可以在上面的基础上引入了 pre-production 分支，用于追踪预发布以及生产环境。即 master 为 pre-production 的 upstream，而 pre-production 为 production 的 upstream ；

发布分支策略

而对于发布软件来说，可以直接在 master 下面，设置多个不同的发布分支，比如各种开源软件：node、mongodb 等。当每次发布新版本时，都会创建一个分支，然后如果有修改的话，也只是继续在 master 上修改，修改完后 cherry pick 到对应的发布分支上。

P.S. 我的思考

其实这么一一说下来，选择就很明显了，尤其我之前提到过 CI 系统搭建。

所以我继续谈谈，Gitlab flow 如何跟自动化结合起来：

比如后端服务器项目，当然选择的是 ** 多环境分支策略 **，那么，当有新代码合并到 pre-production 以及 production 的时候，就可以利用 webhook，通知相应的服务器，自动把代码 pull 下来，执行 pre hook 、重启应用以及 post hook ，这个过程就相当于部署到相应的环境中去。而所谓的 ** 分支追踪 ，也就是为了达到这个目的： 将对应的分支以及各种对应的环境中的代码保持同步 **。

顺便推荐个工具：Git-Auto-Deploy。

另外，Gitlab 还提供了 environment 功能，可以在 .gitlab-ci.yml 中配置，然后直接点击按钮，就可以自动的把代码合并到 pre-production 以及 pre-production 合并到 production 中去。具体可以参考 这个 。

说了这么多，其实也就是想说明：一个规范的流程多么重要，以及当一个流程规范了之后，就可以把重复执行的部分交给机器去做，也就是自动化。

Reference

  1. http://docs.gitlab.com/ee/workflow/gitlab_flow.html
  2. http://nvie.com/posts/a-successful-git-branching-model/
  3. http://scottchacon.com/2011/08/31/github-flow.html
  4. http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

首发于 Github issues: https://github.com/xizhibei/blog/issues/39 ，欢迎 Star 以及 Watch

本文采用 署名-非商业性使用-相同方式共享（BY-NC-SA）进行许可
作者：习之北 (@xizhibei)
原链接：https://blog.xizhibei.me/zh-cn/2017/02/04/git--xie-zuo-liu-cheng/