合并分支？你还在这么干？

最近跟一位朋友讨论这个合并分支，落实到他举例的项目上，我觉得应该记录下来。因为很多公司依旧这么“合并分支”

先说说这位朋友的情况：

老规矩，上个图，简单的最有效。

朋友的做法是这样的，trunk上做新功能，做出来以后，先做该部分的测试，测试好了以后，把该功能merge到branch A, branch A再给A客户使用。

而branch B给另外一个B客户使用，branch C给C客户使用。

到这一切听起来OK，但是问题在哪呢？把新feature merge到branch，这个做法，会导致很多人工的操作到里面，就算在trunk上通过了测试，也不能保证merge到branch A上的时候没有引入新问题。既然A,B,C客户的代码源都是trunk,那么trunk上的代码与branch上代码的区别会越来越大，代码merge时的重构需要的次数就越来越多，越来越久。

久而久之，工作量就大的一两个人无法承担。同时，测试的工作量，因为merge的原因，无法保证测试的结果的正确性。我想，对客户使用上来说，也是不太好的质量体验。

那么，问题来了，如果换做是我，如何做呢？

1.取消从trunk到branch的merge,改成每隔一定时间/功能数拉一次branch。新branch拉出来以后，对应的老branch废弃。

2.做新feature加入开关机制，从而可以控制不同客户的功能给不同客户使用。

3.严格执行trunk只做新feature,branch用来查bug的制度，减少测试负担。

4.trunk上只做新feature部分的UT/MT，branch上做整体测试。

按照以上的要求呢，上面的那个图会变成 这样：

那么如何操作呢？

以客户A那部分为例，新功能a.1提交到trunk后，做UT/MT测试，通过后，拉分支branch A 0.1，该分支给测试人员做IT/ST，通过后发布tag给客户使用。客户使用后肯定有新意见，新修改。那么根据老规则 新修改会加入trunk，比如叫a.2，那么又要拉branch 0.2做测试，又会出tag给客户使用。如此重复，一直到客户找不到问题，最终branch 1.0出山，最终1.0 打tag给客户A使用，客户绝对满意。

那么有人问，trunk上不只A客户的需求啊，我B客户的feature b只提了一半，A客户的feature a.1做好了怎么拉分支啊？

这里，就需要解决方法的第2点了，所有的新feature，由一个配置文件来控制开关，feature b没有开发完成之前，这个开关不打开，那么及时拉出来a.1包含有B客户的代码也不用担心，应为该部分代码并不起作用。该问题就完美解决了。顺便说下，这个配置文件以后还能对不同客户上面不同需求进行配置。

比如说某日你B客户需要A客户的某功能的时候，你可以瞬间收费了后，5分钟就打开该功能。

那么有人问，那么“合并分支“干的事情，这里又如何解决的？

比如a.1新功能完成，拉出来的branch 0.1里面就包含了a.1这个新功能。拉分支只需要svn copy这个命令。不需要人来看代码如何merge，是否要重构，提交可能出现问题的代码了。

至于测试那部分，由于UT/MT都可以由开发人员来做，真正做测试的那部分就到了branch上面。而每个branch都是增量增加功能的，测试部分可以做自动化的。那么测试的effort就变小了。压力也相对减少了。

看到这里，看官们还要做“合并分支”么？