实用 Git 工作流
在 「让代码审核成为你的团队习惯」 一文中，我们分享了我们团队做代码审核的一些经验心得，在微博上引起了热烈的讨论，引出了一些非常有意思的工作流介绍，比如下面的几点。
<p>我们有 master-dev 分支，比较大的功能才会新开 branch，小功能都是直接到 dev 上的，再加上团队在一起开发所以固定时间看昨日的代码，效果还不错。我们同样没有 QA，自己做的 ticket 也会找对方来做测试，但多是功能的完整性上的测试了。<cite> - <a href="http://weibo.com/iamroody" target="_blank">@iarmroody</a></cite></p>
<p>我们团队小，每个开发人员一个 git 分支，基本上工作不会互相打扰。我们的分支策略是，对于新功能，从主干开一个功能分支，然后每个开发在功能分支上开个人分支。合并时，先 BI（Backward Integration)，，再 FI（Forward Integration)。每周四定期合并，合并时 review。之所以放在周四，是因为如果合并出错，周五还有时间修复。<cite> - <a href="http://weibo.com/u/2128792480" target="_blank">@施懿民</a></cite></p>
每个团队都在寻找最适合自己团队的工作方法，希望能提高工作效率和团队协作。我们也是，这也是为什么我们除了代码审查之外，还需要过程审查这类的执行过程。像上面提到的两种方式，肯定也是在各自团队推行中觉得效果不错的，但是个人觉得在过程上在效率上还是有改进空间的，具体理由看下面，可以对比我们的目标和相应方式。目前我们使用的这一套 Git 工作流，是我们这几年不断的过程演进而来，目前 4 个人做 Fengche.co 在用，之前 10 个人做...
......