最近公司产品上线，整个系统架构包含有七八个子系统，并且子系统都是集群部署。所以每次升级维护都要确保尽可能不出问题。因为整个系统刚上线不久，意味着新系统不定期有BUG需修复，但新功能模块也在持续的开发中(可能持续的时间还不短)，所以就引发一个问题：持续开发的新功能代码与生产上的代码 如何进行隔离开来进行维护，而且二者还需要不定期的合并代码。所以就研究了下SVN分支。
首先需厘清SVN的分支以下几个概念：
trunk: 主干(可以理解为开发环境的代码，平常做开发的工作目录)
branches：从主干拷贝了一份代码重新在svn服务器上的建了个分支目录(通常叫branch，一般与生产上的代码保持同步)
tag:主干版本标记（标识每次大的升级版本号）。
我们项目目前的版本管理策略如下（可以根据自已的项目实际需要建立不同的版本管理策略）：
1、系统在没有上线之前，只有一个主干(trunk)，所有开发人员在主干上进行协同开发。
2、系统上线之后，在主干的基础上创建一个分支，该分支上主要用于修复生产环境的BUG，或者紧急新功能上线。主干仍然进行新功能模块的开发。
3、每次生产环境的升级，都从分支上进行打包部署。升级完之后需将分支上改动的代码及时合并到主干上(开发人员常常忘记,切记)。
4、新功能在主干上开发好了，需要进行一次大的升级，可以先将主干打上一个TAG做为大版本号，并且同时在此基础上创建一个对应的分支，然后切换到分支上进行打包部署，这个版本的生产代码维护也在分支上。
原则：分支用于生产代码维护，主干用于平时开发，TAG用于主干大版本的标记。
由于我们项目由好几个子系统构成一个大的集群系统，系统之间的版本统一就显得很重要。所以每次上线，即使相关子系统没有代码改动，也需要重新建立一个分支版本以适应其它子系统的版本改动。
说了这么多之后，来说下具体分支合并到主干上的操作，因为这部分最容易出错：
合并根据目标不同分为2种：
1、分支合并到主干：主要用在修复完生产BUG，并上线之后。需把改动的代码合并到主干上。
2、主干合并到分支：公用的逻辑改动，需反映到所有并行的分支上。
注意：合并是要在目标目录上进行操作的，如：分支合并到主干(主干为目标)，需切换到主干上操作合并功能，主干合并到分支(分支为目标)，需切换到分支上进行操作。
分支合并到主干的具体步骤:
1、主干目录右键选择合并
出现以上6个合并选项，
第一个选项：合并指定的版本，可以是从分支合并到主干，也可以是主干合并的版本，主要作用把分支的部份修改合并到主干上。
第二个选项：复兴分支，这里会把分支上所有的需改都合并到主干上。如果只想合并修改的一部分，并适合这项。
第三个选项：将主干上的修改合并到分支。
第四个选项：2个不同的分支合并，但其实也可以是分支和主干的合并，只要from选择为主干就行。
通常选择第一项或第四项进行操作，这里需要注意的是：
这里其实就是比对TO版本和FROM版本的差异，并把差异合并到TO的当前版本(head版本)中去。
注：如果要把分支所有的修改合并到主干上，FROM需要选择主干创建见分支时的版本号，TO选择分支最新版本（head版本）就行了。
如果FROM也选择主干head版本，TO也选择head版本，就会把所有分支与主干不同的差异覆盖到当前主干上来。造成主干的文件被分支覆盖。
合并当中出现：
no uncommited modified :表示当前版本还有没有提交的文件，如果不需要提交就选择revert.
working copy at a single version：表示当前目录没有从SVN服务器更新最新的版本。update下后在操作就行了。
很久没有写这么长的文章了，希望对大家有帮助。