解决版本冲突问题的方法—分支与合并.docVIP

解决版本冲突－使用SVN主干与分支功能 前言 大多数存在这样一个生命周期：编码、测试、发布，然后重复。trunk、branches、tags另一条线一个分支总是从一个备份开始的从那里开始发展自己独有的历史(如下图所示)在版本控制的系统中，我们经常需要对开发周期中的单独生命线作单独的修改，这条单独的开发生命线就可以称为Branches即分支。分支经常用于添加新的功能以及产品发布后的bug修复等，这样可以不影响主要的产品开发线以及避免编译错误等。当我们添加的新功能完成后可以将其合并到主干中。主要用于项目开发中的里程碑，比如开发到一定阶段可以单独一个版本作为发布等，它往往代表一个可以固定的完整的版本ranches以及ags在TortoiseSVN中创建方法是一致的它们都是通过存储类似Linux中的lunch快捷方式一样，只是创建了指向某个版本的链接，而不会真正将此版本的内容复制到分支或者标记中，这样既可以节省空间，也可以很快速的创建为了便于创建分支和标记，习惯于将Repository版本库的结构布置为:/branches,/tags,/trunk。分别代表分支，标记以及主干。还有一点值得注意的是，SVN不推荐在创建的ag基础上Revision，这种情况应用ranches，因为ag一般保持不变不作任何修改。关于代码管理的分支和发布策略一种是主干作为新功能开发主线，分支用作发布。另一种是分支用作新功能开发，主干作为稳定版的发布。分支管理策略被广泛的应用于开源项目。比如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在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次