源代码主干、分支开发四大模式

1，先锋主干多稳定分支；2，守护主干多先锋分支；3，主干无分支；4，守护主干单分支。

一、先锋主干多稳定分支 

得到一个稳定版本后，将此稳定版本放到一个新分支上，针对此稳定版本的修修补补就在这个分支上进行，新功能不在此分支上开发，而在主干上进行新功能的开发。 这是业界采用较多的模式。

稳定分支上的有些修改，比如缺陷修复，需要合并到主干， 但有些特定修改，是不需要合并到主干的。这时需要千万注意，合并准确的文件到主干。

对于不能合并到主干的情况，常见的是再拉一个分支，这个分支专门为少数特定情况而用，但从全局讲，可能会导致太多分支，不同分支间混乱，所以这并不推荐。推荐宁愿采用配置开关。

比如freebsd的发布就是一个典型的例子。

freebsd的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个stable分支。freebsd是每个大版本一个分支。也就是说4.x，5.x，6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善，而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。以6.x为例，就会有6.0,6.1,6.2…等发布分支。

【此段摘自于网络 http://thinkernel.bokee.com/4518935.html 】

二、守护主干多先锋分支

得到一个稳定版本后，拉出先锋分支，在分支上开发新功能，在主干上进行修修补补。当先锋分支通过一定的测试之后，合并到主干。可以同时有多个先锋分支，不同的功能可以拉不同的分支，不同发布时间点而又要同时开发的内容必须在不同的分支上。

从发布的角度讲，更推荐将肯定一起发布的内容放在相同的先锋分支上。

主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。

这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围了。

【此段摘自于网络 http://thinkernel.bokee.com/4518935.html 】

三、主干无分支

只有主干，没有分支，所有紧急正常的修改全在主干上，开发了一半的东西如果要上线的话，要巧妙的藏起来。对程序的结构提出了高要求，分分合合要方便，开关配置是少不了的了。单从效率讲，这是最高效的模式了。要有不少配套措施才可以。常见的配套措施：每日集成（编译部署测试），静态代码检查，测试不仅仅有单元测试，还有接口测试，还有界面自动化测试。

四、守护主干单分支

只有一个分支，紧急修改在主干上进行，正常开发在分支上进行，主干和分支根据需要双向同步。需要采用与主干无分支相同的配套手段，而且在主干和分支上都需要建设每日集成，甚至持续集成。

以上四种模式是主干分支开发的典型情况。

在实际应用中，前2种更加常见一些，

主干无分支开发时碰到极其特殊情况时，不排除拉短分支。

而在第一个模式先锋主干稳定分支开发时与第三个模式主干无分支，是可以在一段时间内相互转换的。

参考资料

1，代码的分支管理策略 http://thinkernel.bokee.com/4518935.html 

原文链接：http://blog.csdn.net/zhangmike/article/details/38613429