特性分支开发与持续集成

Martin Fowler 最近在用分布式版本控制工具（mercurial/GIT），并写了一篇博文，名为《特性分支 》，主要讨论了使用分布式版本控制工具以后，可能的三种工作方式。（非常佩服Martin Fowler的总结能力。）

 

1. 堆积变更，推迟合并

 

     

在我看来，这种方式的确充分利用了DVCS的灵活性，但显然，不爱频繁提交的开发人员很可能一直发扬这个坏习惯。

 

2. 保持代码主线及频繁提交到主线

 

 

 

这种情况下，大家还是继承了集中版本控制工具(CVCS)了开发方式。由于DVCS提供了每个人本地变更的历史，很方便使用Personal Build实践，即提高了开发效率，又提高了团队持续集成环境中成功build的机会。

 

3. promiscuous integration

 

显然，在这种情况下，两个分支的沟通交流非常充分，但是和主线基本是单向沟通。Martin Fowler也指出：此时，两个分支上的开发人员事先做了充分的沟通（一起出去喝了一杯）”。

 

第二种和第三种可能没有绝对的好坏之分。对于正常的开发过程，我会选择第二种(这是当前Cruise团队开发过程中使用的主要方式)；对于Spike来说，第三种也不错(也是被Cruise开发人员频繁使用的方法，但每次都不会持续太长的时间，否则与mainline合并时，就会出现large merge问题)。

 

而且，我严重同意“CI是一个有效的沟通工具”，除非开发团队不做频繁提交。