1，先锋主干多稳定分支；2，守护主干多先锋分支；3，主干无分支；4，守护主干单分支。
一、先锋主干多稳定分支
得到一个稳定版本后，将此稳定版本放到一个新分支上，针对此稳定版本的修修补补就在这个分支上进行，新功能不在此分支上开发，而在主干上进行新功能的开发。 这是业界采用较多的模式。
稳定分支上的有些修改，比如缺陷修复，需要合并到主干， 但有些特定修改，是不需要合并到主干的。这时需要千万注意，合并准确的文件到主干。
对于不能合并到主干的情况，常见的是再拉一个分支，这个分支专门为少数特定情况而用，但从全局讲，可能会导致太多分支，不同分支间混乱，所以这并不推荐。推荐宁愿采用配置开关。
图片来源于 blog.csdn.net/binnacler/a…
比如freebsd的发布就是一个典型的例子。
freebsd的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个stable分支。freebsd是每个大版本一个分支。也就是说4.x，5.x，6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善，而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。以6.x为例，就会有6.0,6.1,6.2…等发布分支。【此段摘自于网络 thinkernel.bokee.com/4518935.htm… 】
二、守护主干多先锋分支
得到一个稳定版本后，拉出先锋分支，在分支上开发新功能，在主干上进行修修补补。当先锋分支通过一定的测试之后，合并到主干。可以同时有多个先锋分支，不同的功能可以拉不同的分支，不同发布时间点而又要同时开发的内容必须在不同的分支上。
从发布的角度讲，更推荐将肯定一起发布的内容放在相同的先锋分支上。
主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。
这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围了。
【此段摘自于网络 thinkernel.bokee.com/4518935.htm… 】
三、主干无分支
只有主干，没有分支，所有紧急正常的修改全在主干上，开发了一半的东西如果要上线的话，要巧妙的藏起来。对程序的结构提出了高要求，分分合合要方便，开关配置是少不了的了。单从效率讲，这是最高效的模式了。要有不少配套措施才可以。常见的配套措施：每日集成（编译部署测试），静态代码检查，测试不仅仅有单元测试，还有接口测试，还有界面自动化测试。
四、守护主干单分支
只有一个分支，紧急修改在主干上进行，正常开发在分支上进行，主干和分支根据需要双向同步。需要采用与主干无分支相同的配套手段，而且在主干和分支上都需要建设每日集成，甚至持续集成。
以上四种模式是主干分支开发的典型情况。
在实际应用中，前2种更加常见一些，
主干无分支开发时碰到极其特殊情况时，不排除拉短分支。
而在第一个模式先锋主干稳定分支开发时与第三个模式主干无分支，是可以在一段时间内相互转换的。
参考资料
1， 代码的分支管理策略 thinkernel.bokee.com/4518935.htm…
关于代码管理的分支和发布策略，目前我知道的主要有两种模式。
一种是主干作为新功能开发主线，分支用作发布。另一种是分支用作新功能开发，主干作为稳定版的发布。
前一种分支管理策略被广泛的应用于开源项目。比如freebsd的发布就是一个典型的例子。
freebsd的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个stable分支。freebsd是每个大版本一个分支。也就是说4.x，5.x，6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善，而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。以6.x为例，就会有6.0,6.1,6.2…等发布分支。
这种发布方法非常适用于产品线的发布管理。产品是要卖的，以前卖给客户的版本仍需要继续维护，而为了以后的市场，新功能也不断地在增加。这种管理方法对已发布产品的维护工作和下一代产品的开发工作进行了隔离。对于已经发布的产品，只有维护的补丁发布。而新发行的产品不仅包括了所有的bug修改，还包括了新功能。
这种方法也不是没有缺点的。首先，必须对主干上的新功能增加进行控制。只能增加下一个发布里面计划集成进去的新特性。而且，已经在主干上集成的新特性中的任何一个，如果达不到里程碑的要求，稳定分支就不能创建，这很有可能影响下一个发布的计划。开源项目可能这方面的压力小一些，但是商业产品开发如果碰到这种情况就危险了。还有一个缺点就是bug修改必须在各个分支之间合并。从分支和合并的一些实践经验上看，各个长期存在的分支之间必须要周期性的进行合并，否则很容易引发合并冲突。可是各个stable分支以及release分支之间恰好是不能进行合并而且还要长期存在的。因此，采用这种分支策略可能碰到的最大问题就是某个分支上的bug修改内容往其它分支merge的时候出现的冲突。而且一旦发现一个bug，调查这个bug影响哪些分支的工作会随着维护的发布分支的数量而增加。
在非产品开发的外包软件项目里面，这种发布方法的好处体现不出来，而缺点仍然存在。外包项目的特点是客户永远需要“最新”的代码，因此对已经发布的某个分支进行维护的情况很少出现（在测试的时候会出现）。而且发布的方法和产品的发布也不一样。产品的发布，只要把发布分支上的代码编译成安装盘就可以了，而外包的发布往往是把上一次发布和这一次发布之间发生变化的代码送给客户。如果每次发布都是一个分支的话，将会出现两个分支上的比较。强大的版本控制工具当然支持这种比较，但是很多版本工具不支持分支之间的比较，而只支持分支内的不同版本之间的比较。因此为了避免发布方法受工具的限制，就要避免出现分支间比较的情况。针对外包开发的特殊情况，只有采用另外一种分支管理策略。
与第一种分支策略正好相反，主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。
这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围了。
这种发布模式也有缺点。如果某个开发分支因为功能比较复杂，或者应发布计划的要求而长期没有合并到主干上，很可能在最后合并的时候出现冲突。因此必须时刻注意分支离开主干的时间。如果有的分支确实因为特殊的需要必须长期存在，那就必须定期把主干的更新往这个分支上合并。为了减少这种合并发生的次数，并且限定合并的范围，要为每次发布预先建立一个发布分支，然后所有的开发分支根据自己的发布计划向各个发布分支合并。当下一次发布的分支上已经集成了所有的变更并且测试完毕以后，把这个发布分支内容合并到主干，发布主干，然后锁定或者删除这个分支。然后把主干上的所有更新合并到后面几个发布分支里面去。外包项目的发布周期一般都比较短，往往客户验收测试的周期就是发布周期。所以这种方法就够用了。如果发布周期很长，各个发布分支之间还要定期的从前向后合并。这种发布方法还有一个缺点就是测试。不像第一种分支策略，发布的分支就是测试的分支。这种发布模式的测试分支往往是各个发布分支，在正式发布之前才把下一个发布分支上的更新合并到主干，这就引入了合并出错的风险，而主干上的程序是没有经过测试的。幸好从这个发布模式上看，下一个发布分支的合并基础应该和主干上一次发布内容相同，所以引入合并错误的风险很低。还有一种建议就是不设置主干，下一个发布分支就是主干，直接发布下一个发布分支的变更内容，然后把变更合并到再下一个发布分支上去。以此类推。有机会尝试一下。
最后，说说分支合并管理的一些注意点：
1、分支离开主干的时间要尽可能短。长期离开主干的分支需要定期合并。
2、辅助文档是必需的。为了观察分支的创建和合并的过程，至少需要一份类似泳道图的文档标记每一次分支创建和合并的过程。
3、开发分支往主干或者发布分支合并的次数应该尽可能少。一般来讲应该在单体测试结束合并到主干或者发布分支，然后进行结合测试。如果结合测试里发现bug不应该在原来的开发分支上继续修改，而应该创建新的分支进行修改。
4、分支创建和合并的log必须规范。便于以后查找。基本的log信息应该包括从哪个个分支的哪个版本创建分支；把哪个分支的从哪版本到哪个版本范围内的变更合并到了哪个分支的哪个版本，合并后的版本号。这些信息有一些是版本控制工具本身可以很方便查找到的，就可以省略。