myeclipse插件—SVN分支与合并详解【图】

svn作为版本控制软件被广泛用于众多公司的开发团队中，最多的场景就是一个项目上传svn后，一个组内的小伙伴在上边提交和更新代码以及解决冲突，其实这只是发挥了svn的很小的一部分功能。

先稍微介绍一下svn的两种开发和发布的规范：

一 主干修改，分支发布

代码都在trunk上修改，需要发布的时候，从主干上拉出一个版本，如果该版本发现BUG则继续从该分支上修改，并将修改合并到主干上。

二 主干发布，分支修改

任何修改都不能在主干上直接进行，开发新功能，从主干上分支出一个版本，进行开发，发开测试完毕后，在合并到主干上。

个人比较推崇第二种，其优势在于各个分支独立进行，互不干扰，可以使不同开发周期的应用在同一个项目中开发进行。对于同一个应用，a组人开发完毕，b组人只做了一半，这个时候，对于主干修改，分支发布，这样是根本不能发布出去的，而对于主干发布，分支修改，只需要把a组的修改合并回主干就可以发布出去了，b组开发的根本不受影响。

下面介绍一下分支，合并的应用场景，并针对场景进行一个小栗子。

场景1： 采用主干发布，分支修改的规范后，项目要新开发一个功能，这时候我拉开了一个分支，开发完毕后要分支代码合并回主干。

场景2：我在分支的开发过程中，主干被其他的项目组进行较大的改动，为了避免在“正确”（trunk）的道路上走歪了，也为了避免最终合并代码的时候，太过麻烦，我需要将主干的代码合并到分支上来。

场景3：对于同一个文件，同一个方法内的代码合并的时候冲突问题解决。

案例：事先准备工作，我需要在svn创建一个项目test，并创建一个分支test2.0 如图，项目右键--Team-分支

然后刷新一下svn仓库，对比看一下trunk主干和branches分支里面多了一个2.0的test

以下是对上面的三种场景进行详细讲解。

场景1 分支代码合并回主干。 

项目右键-team-先切换到分支代码，然后将分支代码进行改动，然后在切换回主干代码，进行合并操作，如图

然后将分支的修改代码提交svn一下，然后同样切换回主干trunk代码，准备合并。

切换回主干代码后，分支代码修改的地方，主干代码不受影响，还是老样子。

右键team-选择合并，然后选择第二个选项：分支合并到主干

这时候，你就会看到分支的代码被合并到主干上来了，然后提交svn就可以了

场景2 主干的代码合并到分支

和场景1的区别就是:

  a.选择合并方式的时候，选择第一个选项:Merge a range of revisions。

  b.看下面的图。

         

c.然后对分支进行提交。

场景3 冲突解决

再次切换到分支代码，将分支代码更改

然后切换到主干代码trunk，项目右键-team-合并，选择第二项，分支合并到主干，next。就会出现如下图结果，将冲突解决完后，右键-》标记为解决冲突

冲突的代码就解决完了。

最后附带merge input 合并类型截图