作者：张克强 作者微博：张克强-敏捷307
1，先锋主干多稳定分支；2，守护主干多先锋分支。3，主干无分支；4。守护主干单分支。
一、先锋主干多稳定分支
得到一个稳定版本号后。将此稳定版本号放到一个新分支上，针对此稳定版本号的修修补补就在这个分支上进行。新功能不在此分支上开发。而在主干上进行新功能的开发。 这是业界採用较多的模式。
稳定分支上的有些改动。比方缺陷修复，须要合并到主干。 但有些特定改动，是不须要合并到主干的。这时须要千万注意，合并准确的文件到主干。
对于不能合并到主干的情况，常见的是再拉一个分支。这个分支专门为少数特定情况而用，但从全局讲，可能会导致太多分支。不同分支间混乱，所以这并不推荐。推荐宁愿採用配置开关。
图片来源于 http://blog.csdn.net/binnacler/article/details/4274486
比方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 】
二、守护主干多先锋分支
当先锋分支通过一定的測试之后，合并到主干。
能够同一时候有多个先锋分支，不同的功能能够拉不同的分支，不同公布时间点而又要同一时候开发的内容必须在不同的分支上。而对主干上的每一次公布都做一个标签而不是分支。分支上的开发和測试完毕以后才合并到主干。
这样的公布方法的优点是每次公布的内容调整起来比較easy。
假设某个新功能或者bug在下一次公布之前无法完毕，就不可能合并到主干。也就不会影响其它变更的公布。
另外，每一个分支的生命期比較短，唯一长期存在的就是主干。这样每次合并的风险非常小。每次公布之前，仅仅要比較主干上的最新版本号和上一次公布的版本号就能够知道这次公布的文件范围了。
三、主干无分支
单从效率讲。这是最高效的模式了。要有不少配套措施才干够。常见的配套措施：每日集成（编译部署測试），静态代码检查，測试不仅仅有单元測试，还有接口測试。还有界面自己主动化測试。
四、守护主干单分支
须要採用与主干无分支同样的配套手段。并且在主干和分支上都须要建设每日集成。甚至持续集成。