实用 Git 工做流

在 「让代码审核成为你的团队习惯」 一文中，咱们分享了咱们团队作代码审核的一些经验心得，在微博上引发了热烈的讨论，引出了一些很是有意思的工做流介绍，好比下面的几点。

咱们有 master-dev 分支，比较大的功能才会新开 branch，小功能都是直接到 dev 上的，再加上团队在一块儿开发因此固定时间看昨日的代码，效果还不错。咱们一样没有 QA，本身作的 ticket 也会找对方来作测试，但可能是功能的完整性上的测试了。

- @iarmroody

咱们团队小，每一个开发人员一个 git 分支，基本上工做不会互相打扰。咱们的分支策略是，对于新功能，从主干开一个功能分支，而后每一个开发在功能分支上开我的分支。合并时，先 BI（Backward Integration)，，再 FI（Forward Integration)。每周四按期合并，合并时 review。之因此放在周四，是由于若是合并出错，周五还有时间修复。

- @施懿民

每一个团队都在寻找最适合本身团队的工做方法，但愿能提升工做效率和团队协做。咱们也是，这也是为何咱们除了代码审查以外，还须要过程审查这类的执行过程。像上面提到的两种方式，确定也是在各自团队推行中以为效果不错的，可是我的以为在过程上在效率上仍是有改进空间的，具体理由看下面，能够对比咱们的目标和相应方式。目前咱们使用的这一套 Git 工做流，是咱们这几年不断的过程演进而来，目前 4 我的作 Pragmatic.ly 在用，以前 10 我的作 Socialspring 也在用。我的以为很是适合技术型创业团队。

在选择代码级别的项目管理工做流程的时候，咱们但愿能达到这样的目标：

• 可以持续交付：咱们没有固定的发布周期，而是一个更改经过审查就能够直接上线，这样咱们才能很快地发布新的功能或者 bug 修复，也能快速地得到用户对修改的反馈。因此，有时一天里就会有好屡次的发布。
• 方便代码审查：咱们很重视代码审查，具体能够看咱们在「让代码审核成为你的团队习惯」 的分享。因此这个流程必须对代码审查功能很友好。
• 使用代码沟通：代码，是程序员沟通的最直接的手段。咱们但愿每一次的更改提交都是独立的，专一并只专一一件事情。这样，咱们就很容易地去了解此次更改背后要传达的信息了。

因此，为了达到持续交付，咱们必须随时有一个可发布的分支，同时，工做分支能很简单很早的 merge 过来。为了作到随时随地的代码审查，咱们必须每一次更改都要有迹可循，且和其余更改没有交叉。为了方便代码沟通，咱们必须有独立的分支来作独立的事。因此，像开头列出的两种方式，首先代码审查会很麻烦，由于代码容易混在一块儿，不够独立，作不到异步随时审查，而须要你们一块儿花时间专门执行代码审查。同时，会推迟 merge 的发生，带来的更多的不肯定性，好比冲突的增长，时间的拖长等等，就更不要说持续交付了。全部这些，都是效率的杀手，是应该尽可能去避免的。下面看看咱们的工做流程。

咱们有三种性质的分支：1) Master 2) Feature or Bug 3) Staging。全部在时间线上的变化都只跟着 feature 或者 bug 走，跟人无关，也就是项目推动的天然法则。对了，版本控制系统咱们用 Git，而不是 SVN，好处就很少讲了，主要是三点：1) 分布式 2) 建分支很容易 3) merge 很简单。若是你对这个不太了解，能够看看 GitCafe 的 开始 Git 文档。

Master 分支

对于咱们而言，master 分支是很是特别的，它必须是能够部署的分支，也就是一般意义上的 production。好比对于 Pragmatic.ly，如今线上跑的等同于咱们代码里的 master 分支。因此，master 上的任何代码更改都只能是从别的分支 merge 过来，在代码审查事后。

Feature or Bug 分支

咱们开发时不区分功能特性和 Bug，全部都一致按任务处理。因此，为了方便持续交付和代码审查，咱们会人为的细分任务，好比在 9 月份，咱们有下面这些任务计划。

咱们在开始实现这个功能或者修复这个 bug 的时候，就基于 master 支持建立一个新分支。之因此基于 master，正是由于上面提到过 master 永远是能够部署的分支，那么基于 master 开的分支就能够直接被 merge 回 master 作发布。

(yedingding)$ ~/Pragmatic.ly › git checkout -b 754_usage_analytics -t master
Switch to a new branch named "754_usage_analytics"
(terry)$ ~/Pragmatic.ly › git checkout -b 746_integrate_mobile -t master
Switch to a new branch named "746_integrate_mobile"
(roy)$ ~/Pragmatic.ly › git checkout -b 77_comment_via_email -t master
Switch to a new branch named "77_comment_via_email"

从分支建立例子上来看，咱们是按照 <sid>_<ticket title> 的方式来命名。sid 是这个任务在 Pragmatic.ly 的任务 ID，ticket title 是任务在 Pragmatic.ly 上的标题概述。经过每一个任务开发都基于 master 开新分支，就保证了，这个新分支能很容易的跟 master 作 diff 来作代码审查，而后被 merge 回 master。咱们也把这种工做方式集成到了 Pragmatic.ly 中，好比提交到 754_usage_analytics 的 commits 会自动关联到 Pragmatic.ly 这个任务的动态里，也能够在 commit 消息里加上 "ref #754", "resolved #754" 这样的文本，也会自动作关联，以下图。

这里，在建立 pull request 发布作代码审查前，咱们须要先同步 master，也就是 merge master 到正在开发的分支，确保没有 break 和能够正常 merge。而后，团队其余成员会介入作代码审查，固然以前会要求齐全的测试，经过后就能够 merge 会 master 作发布了。用这种方法，须要注意的是，merge 必须得及时，否则若是留下不少个分支没有 merge 的话，解决冲突是个麻烦的事情，更不要说有时会遇到功能有依赖关系的状况时。

Staging 分支

Staging 分支也是一个特殊的分支，是部署到咱们的 staging 服务器上的版本。理想状况下，全部的更改作完代码审查后，在 merge 回 master 发布以前，会先 merge 到 staging 分支，发布到 staging 服务器作人工测试，经过后再 merge 到 master 发布到生产线上。因此，大部分时候，Staging 分支是 master 的一个备份保护，每次测尽量少的改变。因此，仍是会回到同一个注意点，要及时 merge。并且，有时候，根据任务的复杂度不一样，咱们可能不会经过 staging 而是会直接 merge 到 master 分支上线，好比一些简单的 bug 修复。

关于 CI

目前，咱们没有专门的 CI 服务器作持续集成测试，由于在咱们团队的理解力，CI 并非意味着必须有专门的 CI server，而是每一个开发人员在提交代码时必须保证经过了集成测试。因此咱们的作法是发出每一个 Pull Request 的时候，必须确保咱们全部的测试仍然经过。

Pull Request VS Merge Reuqest

严格意义上来讲，咱们使用的是 Merge Request，而不是 Pull Request。Pull Request 要解决的问题是防止远程分支过多形成混乱，这样由每一个开发人员创建本身的一个版本库，在本身的版本库建分支操做，而后往产品生产版本库发起一个 Pull 请求，同时，又要不断的跟远程的产品版本库同步保持一致，对于 10 我的如下的团队，我的感受过重了。像豆瓣这样的团队，为了利用好 Pull Request，专门开发了一整套工具链来自动作这些操做下降复杂度，小团队可能就没这个条件了。而对于开源项目来讲，组织松散，Pull Request 是个很是好的方式。Merge Request 就是我前面一直提到的工做方式，一个远程代码库，多个分支来管理，简单直接。

总结

以上就是咱们代码级别的项目管理工做流程，但愿对你有帮助。我的以为这个流程很适合 lean 的敏捷创业团队，能快速迭代快速交付。大家是怎么作的呢，欢迎交流，能够在微博上直接 @yedingding 或者 @pragmaticly！