标签：配置管理 合并
作者：张克强 作者微博：张克强-敏捷307
1，先锋主干多稳定分支；2，守护主干多先锋分支；3，主干无分支；4，守护主干单分支。
一、先锋主干多稳定分支
得到一个稳定版本后，将此稳定版本放到一个新分支上，针对此稳定版本的修修补补就在这个分支上进行，新功能不在此分支上开发，而在主干上进行新功能的开发。 这是业界采用较多的模式。
稳定分支上的有些修改，比如缺陷修复，需要合并到主干， 但有些特定修改，是不需要合并到主干的。这时需要千万注意，合并准确的文件到主干。
对于不能合并到主干的情况，常见的是再拉一个分支，这个分支专门为少数特定情况而用，但从全局讲，可能会导致太多分支，不同分支间混乱，所以这并不推荐。推荐宁愿采用配置开关。
二、守护主干多先锋分支
得到一个稳定版本后，拉出先锋分支，在分支上开发新功能，在主干上进行修修补补。当先锋分支通过一定的测试之后，合并到主干。
可以同时有多个先锋分支，不同的功能可以拉不同的分支，不同发布时间点而又要同时开发的内容必须在不同的分支上。
从发布的角度讲，更推荐将肯定一起发布的内容放在相同的先锋分支上。
三、主干无分支
只有主干，没有分支，所有紧急正常的修改全在主干上，开发了一半的东西如果要上线的话，要巧妙的藏起来。对程序的结构提出了高要求，分分合合要方便，开关配置是少不了的了。单从效率讲，这是最高效的模式了。要有不少配套措施才可以。常见的配套措施：每日集成（编译部署测试），静态代码检查，测试不仅仅有单元测试，还有接口测试，还有界面自动化测试。
四、守护主干单分支
只有一个分支，紧急修改在主干上进行，正常开发在分支上进行，主干和分支根据需要双向同步。需要采用与主干无分支相同的配套手段，而且在主干和分支上都需要建设每日集成，甚至持续集成。
以上四种模式是主干分支开发的典型情况。
在实际应用中，前2种更加常见一些，
主干无分支开发时碰到极其特殊情况时，不排除拉短分支。
而在第一个模式先锋主干稳定分支开发时与第三个模式主干无分支，是可以在一段时间内相互转换的。
主干分支开发四大模式,布布扣,bubuko.com
主干分支开发四大模式
标签：配置管理 合并
原文地址：http://blog.csdn.net/zhangmike/article/details/38613429
