TortoiseSVN中分支和合并实践

太过爱你忘了你带给我的痛 2022-09-25 00:21 142阅读 0赞

使用svn几年了，一直对分支和合并敬而远之，一来是因为分支的管理不该我操心，二来即使涉及到分支的管理，也不敢贸然使用合并功能，生怕合并出了问题对团队造成不良影响，最主要的原因是，自己对分支的目的和合并的方法不甚了解，这才是硬伤。

最近由于适配机型的需要（本人从事手机客户端的开发），需要经常接触分支和合并两项工作，突然发现这玩意整不明白很难开展工作，遂这两天着重研究了一下，有点收获，怕以后忘了，故趁着余温尚在赶紧写下来，好记性不如烂笔头嘛。下文的实践主要是参考了TortoiseSVN的帮助文档和Subversion的在线文档，Subversion的在线文档：[http://svnbook.red-bean.com/en/1.5/svn-book.html][http_svnbook.red-bean.com_en_1.5_svn-book.html]

话说我公司现在的源代码管理挺乱的，svn目录并没有采取标准的source/branches、source/trunk结构，主线和分支放得到处都是，release版本也并没有当成tag处理，而是当成branch来管理，经常还要在release版本上改来改去。。。

先说说什么是branch。按照Subversion的说法，一个branch是某个development line（通常是主线也即trunk）的一个拷贝，见下图：

![0_1310635624026O.gif][]

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

下面我将step by step地演示如何一次完整的branching和merging，包括创建分支、分支开发、分支和主线同步，分支合并到主线的全过程，甚至包括如何在本地创建一个测试用的repository。

首先需要安装TortoiseSVN，我安装的版本是：TortoiseSVN 1.6.15, Build 21041 - 32 Bit , 2011/03/23 18:00:27

**1、本地Repository的创建**

repository的创建很简单，假设我要在D:\\TortoiseSVN\\TestRepository目录中创建repository，只需右键TestRepository目录，依次选择"TortoiseSVN" -> "Create repository here"便完成了repository的创建。

**2、Check out**

假设要check out到D:\\TortoiseSVN\\TestSVN，同样很简单，在D:\\TortoiseSVN目录下创建TestSVN目录，然后在该目录上右键，选择"SVN Check out..."，在弹出的窗口中的"URL of repository"中填入"file:///D:/TortoiseSVN/TestRepository"，其他默认即可，最后点击ok。

**3、trunk创建新项目MyProject**

相当简单就不赘述了，只列出本次操作所作出的修改：

![0_1310654241E8hh.gif][]

**4、创建branch**

在/trunk/MyProject目录上右键，依次选择"TortoiseSVN" -> "Branch/tag..."，在弹出窗口的"To URL"中填入分支的地址，在这里目标revision选择HEAD revision，如下图所示，添加log后点击ok分支便建立了。这个操作速度非常快，新建的branch在repository中其实只是一个指向trunk某个revision的软连接而已，并没有真的复制文件。

![0_1310654533q26t.gif][]

**5、Check out分支**

右键TestSVN目录选择"TortoiseSVN Update"即可将刚刚建立的分支下载回本地。进入/branches/MyProject目录下你会发现其文件结构和/trunk/MyProject一模一样。

**6、branch提交一个新文件**

![0_1310655182jGGW.gif][]

**7、trunk紧接着提交一个修改**

![0_131065523464l9.gif][]

**8、branch再次提交一个修改**

![0_1310655316Fc0M.gif][]

**9、将trunk中的修改同步到branch**

6-8演示的是branch和trunk在独立、并行地开发。为了防止在“错误”的道路上越走越远，现在branch意识到是时候和trunk来一次同步了（将trunk合并到branch）。

首先，在本地trunk中先update一下，有冲突的解决冲突，保证trunk和repository已经完全同步，然后在/branches/MyProject上右键，依次选择"TortoiseSVN" -> “Merge...”，在弹出的窗口中选择第一项"Merge a range of revision"，这个类型的Merge已经介绍得很清楚，适用于将某个分支或主线上提交的多个revision间的变化合并到另外一个分支上。

![0_13106558532uPR.gif][]

点击next后，出现如下窗口：

![0_13106562442ZQZ.gif][]

由于是要从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只需填4即可。点击next后出现下图：

![0_1310656626mx9H.gif][]

在这里只需保留默认设置即可。在点击Merge按钮前你可以先Test merge一把，看成功与否，以及merge的详细信息。点击Merge按钮后trunk所做的修改将同步到branch中。

**10、提交合并后的branch**

![0_13106569839g4f.gif][]

至此，branch已经完全和trunk同步，branch和trunk的代码相处很融洽，没有任何冲突，如果branch已经开发结束，那是时候将branch合并回trunk了，当然，如果branch还要继续开发，那你将不断地重复6-10这几个步骤。

**11、将branch合并回trunk**

在/trunk/MyProject上右键（注意是在主线的目录上右键），依次选择"TortoiseSVN" -> "Merge..."，在弹出的窗口中，Merge type选择第二项"Reintegrate a branch"，这种类型的合并适合在分支开发结束后将所有的改动合并回主线。

![0_13106573597hYb.gif][]

点击next后出现如下窗口：

![0_131065774486Zw.gif][]

在这里，"From URL"选择/branches/MyProject，无需选择revision号，Reintegrate会将branch上所有修改合并到trunk。后面的步骤和上文第9步中的一样，不再啰嗦了。如无意外，branch将成功合并到trunk，你需要做的只是将合并后的trunk赶紧commit！

**12、提交合并后的trunk**

so easy...

**13、删除branch**

如果你认为你新加的功能已经开发完成了，你可以删除你的分支

到这里，我已经给你演示完了整个过程，我一身的汗也下来了，我想罢工了，不过最后我们还是看看所有的log信息吧，通过log能发现我们干的所有事情：

![0_1310658093DCD2.gif][]

r1-r7正是我上文在干的事情，从Message中你能发现我对trunk和branch都干了什么，另外，在Log Messages窗口的左下角勾选了"Include merged revisions"你还能看到额外的Merge information：

![0_1310658311B1x5.gif][]

图中灰色的是和merge相关的log，共发生了两次merge，第一次是在r6，在r6中，branch合并了trunk在r4时提交的变化；第二次是在r7，在r7中，trunk合并了branch从r2到r6的所有变化。

终于可以写写总结了：

*  branch主要用于新功能的开发
 *  合并发生在本地working copy，只要你不提交就不会影响到repository
 *  合并前一定要先update、commit，保证不会out of day，并将本地的修改保存到repository
 *  branch和trunk并行开发的过程中，要经常同步，将trunk的修改合并到branch，合并时选择"Merge a range of revision"
 *  branch最后合并回trunk时，merge type选择"Reintegrate a branch"

\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#

合并的工作是把主干或者分支上合并范围内的所有改动列出，并对比当前工作副本的内容，由合并者手工修改冲突，然后提交到服务器的相应目录里。如果当前工作副本是主干，则合并的范围是分支上的改动，如果工作副本是分支的，则合并范围是主干上的改动，并且一定要注意，合并的起始位置URL一定要和当前的工作副本的URL是相同的。

**一、合并一个范围的版本（Merge a range of versions）**

此类型应用最为广泛，主要是把分支中的修改合并到主干上来。在主干上点击右键选择合并，然后选择合并类型：合并一个范围的版本。合并的源URL填写的是要合并的分支的URL，待合并的版本范围如果为空，则指的是合并分支上所有的版本，即自从分支创建以来到分支当前最新版本的所有演变。如果只是选择其中一个版本，或者几个版本，那么就表示只是将制定的n个版本的变化合并到主干上。如果只是选择其中一个版本，那么表示只是选择那个版本的修改，之前或之后的修改将不被采纳。

**二、复兴合并（Reintegrate a branch）**

复兴合并可以理解为是第一种合并类型的一种特例，在复兴合并中，主干可以理解为是自从开创分支之后没有任何修改，而分支是经过修改的，而且合并中分支是没有版本选择的。经过复兴合并，分支中所有的修改都会合并到主干中，合并的结果将使得分支和主干一模一样，从而可以删除分支。

**三、合并两个不同的树（Merge two different tress）**

此类型与前两种类型不同，第一种类型可以选择分支合并的版本，主干不能选择版本；第二种类型是主干和分支都不能选择合并的版本；而这种类型则是无论是主干还是分支都可以选择合并的版本，即可以选择过去的一个主干版本与分支的某个版本进行合并。合并的时候以选择的分支版本为主，如果选择的主干版本与分支版本有不同的地方，合并时主干部分将被放弃。

起始URL：选择主干目录的URL（应当和当前工作副本的URL一致，这个是所谓的合并点）

结束URL：选择要合并的分支的URL。

起始和结束的版本：一般起始版本应当找到最后一次同步时的版本，如果从没有同步过（第一次合并），则选择创建分支时的版本，结束版本一般是最新版本，如果你不想将某些内容合并进主干的话，也可以选择一个合并点。

\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#

# SVN中Branch和tag优劣大比拼 #

本节主要讲解一下在SVN中Branch和tag的比较，SVN中Branch和tag在一个功能选项中，在使用中也往往产生混淆。在实现上，branch和tag，对于svn都是使用copy实现的，所以他们在默认的权限上和一般的目录没有区别。至于何时用tag，何时用branch，完全由人主观的根据规范和需要来选择，而不是强制的（比如cvs），下面我们就来看一下SVN中Branch和tag的具体介绍。

SVN中Branch和tag的比较  
在SVN中Branch和tag在一个功能选项中，在使用中也往往产生混淆。在实现上，branch和tag，对于svn都是使用copy实现的，所以他们在默认的权限上和一般的目录没有区别。至于何时用tag，何时用branch，完全由人主观的根据规范和需要来选择，而不是强制的（比如cvs）。

一般情况下，tag，是用来做一个milestone的，不管是不是release，都是一个可用的版本。这里，应该是只读的。更多的是一个显示用的，给人一个可读（readable）的标记。  
branch，是用来做并行开发的，这里的并行是指和trunk进行比较。比如，3.0开发完成，这个时候要做一个tag，tag\_release\_3\_0，然后基于这个tag做release，比如安装程序等。trunk进入3.1的开发，但是3.0发现了bug，那么就需要基于tag\_release\_3\_0做一个branch，branch\_bugfix\_3\_0，基于这个branch进行bugfix，等到bugfix结束，做一个tag，tag\_release\_3\_0\_1，然后，根据需要决定branch\_bugfix\_3\_0是否并入trunk。对于svn还要注意的一点，就是它是全局版本号，其实这个就是一个tag的标记，所以我们经常可以看到，什么什么release，基于xxx项目的2xxxx版本。就是这个意思了。但是，它还明确的给出一个tag的概念，就是因为这个更加的可读，毕竟记住tag\_release\_1\_0要比记住一个很大的版本号容易的多。

SVN中Branch和tag建立的方法比较简单，totoiseSVN中的操作是:  
1.选择Branch和tag..  
2.在出来的界面中的ToURL中填上URL，一般是svn://IP/Project/branches/branch-1,这样就建立了一个branch-1的branch.建立tag是一样的操作，只不过URL一般是svn://IP/Project/tags/tag-1  
3.后面的Createcopyfrom是用于选择从你当前的workingbase中的哪个版本中建立Branch和tag，可以根据自己的选择来订制，一般选择HeadRevision  
subclipse中几乎是一样的操作。

Merge分为很多种:  
1.多个branch之间merge  
2.branchmerge到trunk  
3.trunkmerge到branch  
第2种用的比较多，比如在otfs接口中netamount的需求提出后就得建立一个netamount的branch，trunk继续在非netamount的情况下继续开发，netamount单独开发，当netamount功能测试通过后，将netamountbranchmerge到trunk下，然后将trunkrelease。第3种情况用的也不少，如上的例子，当用户进行netamount测试时，如果用户不想只测试netamount的功能，则需要将trunk中的修改merge到netamountbranch，然后从netamountbranch中发布一个版本供用户测试。

branch merge to trunk在tortoiseSVN操作如下:  
1.选择TortoiseSVN->Merge  
2.选择Reintegrateabranch  
3.选择FromURL,URL填好之后可以点击ShowLog,可以看看这个branch是否是你要merge的内容,下面的Workingcopy中也可以ShowLog，可以确认一下你的工作目录是否是trunk。确认后点击Next  
4.MergeOptions里面有些选项，根据需要来选择，TestMerge按钮会告诉你这次Merge会做哪些操作，最好先TestMerge一下!如果是预期的Merge操作，点击Merge则可以将branchMerge到本地工作目录下  
5.有冲突的文件需要解决好冲突，解决之后点击svncommit则完成了merge

SVN中Branch和tag比较介绍时从多个revision中merge到本地工作目录在tortoiseSVN的操作如下:  
1.选择TortoiseSVN->Merge  
2.选择Mergearangeofrevisions  
3.URLtomergefrom填上merge的来源，merge来源一般和你的workingcopy是不同的branch或者workingcopy是trunk而mergefrom是branch  
4.Revisionrangetomerge填上需要merge的revision，格式是1,3,5或者1-10  
5.后续操作同Reintegrateabranch

subclipse进行Merge操作同tortoiseSVN的操作方式有所区别，原理基本同Mergearangeofrevisions。  
点击Team->Merge后，只有一个界面，这个界面提供了两种Merge操作方式:  
1.Merge某个版本范围内的修改到本地工作目录上  
2.Mergefeaturebranch到trunk(也需要先merge到本地)  
第1种的操作方法是:  
1.在fromurl中填上branch的url  
2.fromrevision中选择建立这个branch的revision号,不是最新的那个版本号!  
3.tourl框中勾上"Use'From:'URL"这个checkbox,ToRevision中选择需要需要Merge到的revision号，一般勾headrevision  
4.Dryrun让你预览一下merge效果，UnifiedDiff将Merge的两边进行Diff并将Diff结果保存到文件中。(在我机器中Dryrun没有窗口出来，diff结果的文件除非只有很小的变化，不然看得头大)  
5.点击Merge将merge到本地，这时候与版本库进行一下同步应该和上一步的dryrun有同样的效果，如果merge过来的东西不是你预期的更改可以选择revert，但是新增的文件需要手工删除!如果是预期的merge效果，那commit，记得在comments中写上merge来的branch、fromrevision、torevision(不要写head，写数字)总的来看subclipse的merge操作并不方便，不如tortoiseSVN。SVN中Branch和tag的比较介绍完毕。

参考文献：

[SVN版本管理规范1.4][SVN_1.4]

[SVN版本库管理][SVN]

[http_svnbook.red-bean.com_en_1.5_svn-book.html]: http://svnbook.red-bean.com/en/1.5/svn-book.html
[0_1310635624026O.gif]: /images/20220719/ab3b568f3397420e967ca3e92984aec2.png
[0_1310654241E8hh.gif]: /images/20220719/d07e5af9bb164b12a01a9453b430150a.png
[0_1310654533q26t.gif]: /images/20220719/984ae589d7e34063934702217fe578a2.png
[0_1310655182jGGW.gif]: /images/20220719/a044fd71261443a08900ceaac0808217.png
[0_131065523464l9.gif]: /images/20220719/ded15e225094478fb4075c17a480a17b.png
[0_1310655316Fc0M.gif]: /images/20220719/405d9f0a9a6b413b9372436dec5a3d01.png
[0_13106558532uPR.gif]: /images/20220719/603bb711c7d34bc68436abd73892120c.png
[0_13106562442ZQZ.gif]: /images/20220719/67b692d05304462c94d12e4a2ef009d3.png
[0_1310656626mx9H.gif]: /images/20220719/f9d4208577784411ab1828b90c9cd9f5.png
[0_13106569839g4f.gif]: /images/20220719/9cdaf1f9776e49c4b1b9d0daefe9edaf.png
[0_13106573597hYb.gif]: /images/20220719/1d8d7622d6ec44d58259ef412e36530e.png
[0_131065774486Zw.gif]: /images/20220719/89f398dc96564fbdb8e7e7962ec1ba96.png
[0_1310658093DCD2.gif]: /images/20220719/b25921c344b24735b46f9be4c945bf60.png
[0_1310658311B1x5.gif]: /images/20220719/93208056594d44d8b36cf65287aa11d8.png
[SVN_1.4]: http://wenku.baidu.com/link?url=fbNNfaKb8eb8oZ6bn_LVOEO8xhLLtJQCFyFCARBLcJIl3w-eJmIEIWuDyp6ahdVZAZ3nOVOMsHh0tPJ6ItRGODYXgAJpauEzkjLa9iJJyCa
[SVN]: http://blog.sina.com.cn/s/blog_71b8212d0100qxyd.html