svn分支和合并实战（图解）

被svn分支和合并折腾了两天了。适才终于搞定了分支和合并的问题，打包部署成功了。总结下，以防遗忘。项目前段时间因为要加入OSGi的blueprint方法发布和获取服务，从svn主干上做了分支。如今分支的开发完成了，要求合并到主干中。svn的目录结构如下：

主干trunk：

https://192.168.0.11:8443/svn/code/product/trunk/项目名称/code/OSGiServer/plugins/com.tzf.svn.test

tag：

https://192.168.0.11:8443/svn/code/product/tag

分支branches：

https://192.168.0.11:8443/svn/code/product/branches/项目名称/code/OSGiServer/plugins/com.tzf.svn.test

 

先 从http://subversion.apache.org/packages.html#windows 下载win2svn文件：Setup-Subversion-1.6.13。安装，在cmd下，svn 命令就可以了。下载这个的作用有两个：查看分支分出时的版本和解决合并冲突。

 

我这里是从分支合并到主干，

被操作对象： 主干（合并的目标）

From ： 主干的 打出分支时的版本

To： 分支的 Head版本 （最新版本）

怎么理解这个 From 和 To 呢 ? 似乎跟我们的想当然不太一样：因为我们理解，把分支合并到主干，肯定是 From 分支，To 主干。怎么搞反了呢？

实际上， Svn 认为，我们要合并的，是从主干的某个版本开始，到分支的某个版本结束。两边的版本号实际上是一套系统，不会有重复。

 

比如我主干的结构如下：

 

 

现在在分支里做点修改，比如我加个类叫Bean2.java，并且提交。如图：

 

好啦，现在将工程切换到主干里，因为从分支合并到主干，被操作对象是主干工程。

要合并得知道分支分出去时的版本号，cmd打开命令行，使用svn log --verbose --stop-on-copy branch_path查看版本更新信息，如图：

 

找到最下版本信息，这里就是r8623，记住这个版本号，以后合并的from就是从这个版本号开始的。to就是指你想要合并的版本号，一般都是最新版本，当然也可以是指定版本。

切换到主干，选中工程，右键team -> 合并：

 

from就是分支或主干的路径，下面选择的就是刚刚记下的分支分出的版本号，to这里就是合并到那个版本，我这里选择的最新版本。点finish，如果文件有冲突就弹出询问框，选择现在暂时不处理就行。

我这里没有出现文件冲突，点ok就基本大功告成。这时需要在主干里体检带修改符号的文件，完成提交就搞定了合并。

如果文件冲突了怎么办呢，在命令行下进入冲突文件的目录，用svn命令行客户端键入：svn resolved 冲突的文件名  就可以解除冲突。

好了这是从分支到主干的合并。还有两种合并：从主干到分支和从分支到分支，操作也是大同小异。具体参考如下：

 

从主干合并到分支

试想这样的情况：一个项目里面，要独立出来一个子项目，需要单独发布版本，用到了基础框架代码，而基础框架在主干中不断修改完善，这就需要从主干合并到分支。

被操作对象： 分支

From： 分支的第一个版本（最旧版本）

To： 主干的Head版本（最新版本）

相当于从分支的第一个版本开始一直到主干最后一个版本结束合并之后，替换分支。

从分支合并到分支

有 这样的需求：一个项目中有很多分支，这些分支需要分期上线，有多个工作并行，但每一期之间不能相互影响，这就可以打出几个tag（也是分支），从主干 copy而来。其他主干根据排期分别合并到这些tag中来。比如有prjTag1和prjTag2，model1、model2需要合并到prjTag1 中，model3、model4需要合并到prjTag2中。拿prjTag1举例：

在prjTag1的work copy中，merge

From ： 主干的 打出分支时的版本

To： 分支的 Head版本 （最新版本）

注意： From不是本Tag的某个版本，而是之前主干打出分支时的版本，最终Merge到prjTag1的work copy，而prjTag1是找不到当初打分支时的版本的。

迷惑的主要原因是这个命令的名称，术语“合并”不知什么原因被用来表明分支的组合，或者是其他什么神奇的数据混合，这不是事实，一个更好的名称应该是svn diff-and-apply，这是发生的所有事件：首先两个版本库树比较，然后将区别应用到本地拷贝。 

这个命令包括三个参数： 
初始的版本树（通常叫做比较的左边）， 
最终的版本树（通常叫做比较的右边）， 
一个接收区别的工作拷贝（通常叫做合并的目标）。 

一旦这三个参数指定以后，两个目录树将要做比较，比较结果将会作为本地修改应用到目标工作拷贝，当命令结束后，结果同你手工修改或者是使用svn add或svn delete没有什么区别，如果你喜欢这结果，你可以提交，如果不喜欢，你可以使用svn revert恢复修改。 

为了表示你的分支上的修改，你只需要比较分支的初始状态与最终状态，在你的分支上使用svn log命令，你可以看到你的分支在341版本建立，你的分支最终的状态用HEAD版本表示，这意味着你希望能够比较版本341和HEAD的分支目录，然后应用这些分支的修改到主干目录的工作拷贝。 

其实使用这个功能后的过程是把To的版本和From版本进行对比，然后把之间的差异合并到当前的版本中。比如要把一个分支的修改全部给合并进来，From就应该选择主线创建了分支的那个版本，To就应该选择分支的Head版本。 

如果版本选择的不正确，比如说From选择了主线的Head版本，就会把所有分支和主线Head不同的文件都覆盖到主线上来，造成主线上修改信息的丢失。 

注意：

1.分支与分支比较

2.工作目录把比较的结果记录下来

3.再把比较结果提交到SVN