关于代码管理的分支和发布策略，目前我知道的主要有两种模式。
一种是主干做为新功能开发主线，分支用做发布。
另外一种是分支用做新功能开发，主干做为稳定版的发布。
前一种分支管理策略被普遍的应用于开源项目。好比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信息应该包括从哪一个个分支的哪一个版本建立分支；把哪一个分支的从哪版本到哪一个版本范围 内的变动合并到了哪一个分支的哪一个版本，合并后的版本号。这些信息有一些是版本控制工具自己能够很方便查找到的，就能够省略。 并发