情景和svn多分支合并原理
使用svn好多年了(期间也有使用git)，一直对分支和合并敬而远之，一来是因为没有特别紧迫的需求，二来即使涉及到分支的管理，也不敢贸然使用合并功能，生怕合并出了问题对团队造成不良影响，最主要的原因是，自己对分支的目的和合并的方法不甚了解，这才是硬伤。
最近涉及电商项目开发和源码管理，由于紧急活动需求比较多，又要兼顾新的future的开发，需要经常接触分支和合并两项工作。突然发现这玩意整不明白很难开展工作。遂这两天着重研究了一下，有点收获，怕以后忘了，故趁着余温尚在赶紧写下来，好记性不如烂笔头嘛。文章内容主要参考网上的经验和自已的实践。TortoiseSVN的帮助文档和Subversion的在线文档，Subversion的在线文档：http://svnbook.red-bean.com/en/1.5/svn-book.html
先说说什么是branch。按照Subversion的说法，一个branch是某个development line（通常是主线也即trunk）的一个拷贝，见下图：
branch存在的意义在于，在不干扰trunk的情况下，和trunk并行开发，待开发结束后合并回trunk中，在branch和trunk各自开发的过程中，他们都可以不断地提交自己的修改，从而使得每次修改在repository中都有记录。
设想以下场景，如果你的项目需要开发一个新功能，而该功能可能会修改项目中的绝大多数文件，而与此同时，你的另一位同事正在进行bug fix，如果你的新功能不在branch中开发而直接在trunk中开发，那么你极有可能影响另一位同事的bug fix，他/她在bug修复中可能会遇到各种各样的问题，因为你的频繁提交代码引入了过多的不稳定因素。你可能会说，那我在开发的过程中不提交不就行了，等到我全部开发结束我再提交，是，你可以这么做，那还要版本控制干什么呢？也许等到你最后提交代码的时候（也许一周，也许两周？），你会发现有一大堆conflict等着你resolve。。。
那么，正确的做法是什么？使用branch，从trunk创建branch，然后在你的branch上开发，开发完成后再合并到trunk中。
关于branch先讲到这里，下面说说什么叫做合并。很好理解，当branch开发完成后（包括必要的测试），将branch中的修改同步到trunk中，这个过程有可能包括修改文件、增加文件、删除文件等等。
说到这里，貌似本文差不多可以结束了，不就是分支和合并么？只要再简单地说说如何建立分支和如何合并就可以收尾了，可能只需两个命令，也可能只需鼠标点几下然后键盘敲两下即可。其实事情远非这么简单，爱动脑筋的同学可能会问了，将branch的改动merge到trunk的时候，和上文说的直接在trunk中全部开发完然后提交有何区别？你最后还不是要处理一大堆conflict？
这个问题问得非常好，其实这正是本文的重点：branch和trunk在并行开发的过程中如何感知对方，branch如何才能在开发过程中不会和trunk越走越远，导致最后无法合并？试想一下，如果在你开发branch的过程中，trunk中的某个类文件已经被删除了（这可能是另外一个家伙在另一个branch上开发了两周后才合并到trunk的），而你竟然在这个类文件上做了大量修改，试问你到最后合并回trunk的时候该有多蛋疼？解决这一问题的唯一手段是，branch要不停地和trunk保持同步，你要及时地知道trunk都做了什么修改，这些修改是否会影响你正在开发的新功能，如果需要，你必须及时调整branch的代码，使之能与trunk“兼容”。
那么如何让branch和trunk保持同步？合并，从trunk合并到branch，你没听错，是从trunk合并到branch。关于TortoiseSVN的合并，有几点需要注意：
- TortoiseSVN的合并发生在本地，也即你的working copy中，你无需过多担心会对repository中的代码造成影响
- 不管是从trunk合并到branch还是最终从branch合并回trunk，在每次合并前最好先update，然后将本地的修改先全部commit，保护好现场，万一合并不理想随时都可以revert
- 合并完成后看是否能正确编译，然后测试验证，最后将合并后的改动提交到repository
环境说明
- svn(1.8)、tortoiseSVN(svn客户端)
- idea
我们svn代码管理是基于分支开发的，不断合并到主干，基于主干测试和打tag发布。主干trank上普通开发人员是没有权限的，只有研发经理有权限。所以多分支开发，是基于trank打多个开发分支:如branch_activity,branch_new-future。一般一个开发分支是不是会问题的，每次从开发分支merge到主干提测，和单分支开发也差不多。当多个分支的时候，分支合并就会出现代码覆盖、冲突等问题。
合并实践
-
使用idea 合并分支
Integrate Project :这种在分支间整合，只能全量merge，不能一个revision，一个revision的处理。两个分支差异较大时，合并存在覆盖和丢失代码的情况。适合从branch全量合并到trunk上，这块可以参考下文，使用小乌龟工具合并分支代码。
merge from:
使用过程，如下截图说明。可以选择相对应的revision，部分合并，效果比较好。但是有时候比如，有的分支上有文件已经删除，在另一个分支上有修改，这时候可能idea会异常退出svn merge，这个我考虑是idea的bug。这种情况，可以选择使用tortoiseSVN合并工具，这个svn客户端应该跟svn的兼容性更好。
-
使用tortoiseSVN工具合并分支
[参考]https://blog.csdn.net/eggcalm/article/details/6606520
在/branches/MyProject上右键，依次选择"TortoiseSVN" -> “Merge…”，在弹出的窗口中选择第一项"Merge a range of revision"，这个类型的Merge已经介绍得很清楚，适用于将某个分支或主线上提交的多个revision间的变化合并到另外一个分支上。
点击next后，出现如下窗口：
由于是要从trunk合并到branch，理所当然这里的"URL to merge from"应该填trunk的路径，"Revision range to merge"很好理解，就是你要将trunk的哪些revision所对应的变化合并到branch中，可以是某一连串的revision，比如4-7，15-HEAD，也可以是某个单独的revision号。由于在r4中，trunk修改了Person.java中的talk()方法，所以这里的revision为选择的要合并的revision(or revision组)即可。点击next后出现下图：
在这里只需保留默认设置即可。在点击Merge按钮前你可以先Test merge一把，看成功与否，以及merge的详细信息。点击Merge按钮后trunk所做的修改将同步到branch中。
提交合并后的branch:
至此，branch已经完全和trunk同步，branch和trunk的代码相处很融洽，没有任何冲突，如果branch已经开发结束，那是时候将branch合并回trunk了，当然，如果branch还要继续开发，那你将不断地重复trunk 2 branch步骤。
将branch合并回trunk:
在/trunk/MyProject上右键（注意是在主线的目录上右键），依次选择"TortoiseSVN" -> “Merge…”，在弹出的窗口中，Merge type选择第二项"Reintegrate a branch"，这种类型的合并适合在分支开发结束后将所有的改动合并回主线。
点击next后出现如下窗口：
在这里，"From URL"选择/branches/MyProject，无需选择revision号，Reintegrate会将branch上所有修改合并到trunk。后面的步骤和上文第9步中的一样，不再啰嗦了。如无意外，branch将成功合并到trunk，你需要做的只是将合并后的trunk赶紧commit！
总结
- 一般分支合并使用idea等IDE就可以了，trunk到branch使用merge revision range,branch合到trunk使用integrate a branch.
- 如果实在合并不了，因为ide跟svn可能有兼容性问题，终极工具就是tortoiseSVN。
- 合并的过程都在本地工作空间，不用担心svn库代码乱了，本地处理代码没有问题了，再commit到svn对应分支。
希望对您有帮助，更多分享，欢迎关注本人公众号:猿来在此。↓↓↓
