4种常见分支模式解析及优劣对比

团队研发的本质

我们曾经接触到一家企业，它一开始只有8个人，那个时候每个月都可以发一两个版本出去，客户都可以用到，因为他们是做医院的信息管理HIS系统。他们觉得做得还不错。后来团队发展比较快，规模到了80人左右，却半年没发一个版本。这导致实施团队没脸见客户，因为客户说半年前提的需求怎么还发不出来。

这个时候悖论就来了：我们以为团队规模越大，研发效率就会越高，可以做越多的东西，但是我们发现团队规模大到一定程度，整个研发效率是会下降的，甚至降得非常快。

站在团队的角度来说，因为人多，协作越来越慢，协作的成本也越来越高。我们发现团队的研发模式，人越多越会有问题，因为冲突更多，等待更多。这里冲突是指代码集成发布过程中的冲突，而等待也是集成和开发过程中代码彼此的等待。

以下是两个具体的场景。

假设有两个程序员A和B一起工作，A一开始每次提交都把工作逐渐成功提交到线上去，然后B提交了一个版本，导致编译失败了。这时，A就无法提交，因为提交就会挂，要等待B修复问题才能提交，这时A的提交和B的工作就产生了冲突。

第二种情况，多个分支往同一个分支合并，FeatureA先合进主干，FeatureB晚了一点结果发现无法合并，因为基线不一样了，这时候必须先解决掉代码冲突才能合进去。

如上图，假设现在有3个人，A、B和测试C，每个人的点代表它做的任务，比如A一直在做自己的事情，每完成一个事情就开始做下一个事情，做完第三个事情的时候他觉得需要去找B联调一下，就给B发了一个ping，但是B有自己的节奏，在忙他自己的任务，所以并未马上响应A的请求。他发现有一个任务可以提测了，他就告诉了C，C发现有问题就马上Pong了回去，但是这时B在忙另外一个任务，没有响应。C发现B无响应，又发了一次Pong，这时B看到了A和C的消息，他先处理了A的事情，给A回复了一个Pong的消息。

我们发现，程序员和程序员，测试人员和开发人员之间，在整个的开