svn关于分支管理与应用 branches, merge

安装 TortoiseSVN

SVN官方文档 http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.whatis

创建 D:\dev\repo\test 仓库

右键 test --> Create repository here

仓库地址 file:///D:\dev\repo\test

点击 Create folder structure 创建目录结构

点击 Start Repobrowser 就看到了三个分支目录 trunk, tags, branches

点击 OK ，仓库就建好了。

创建 D:\dev\work

右键 work --> checkout

填入 file:///D:\dev\repo\test

就看到 work 下多出了三个目录
trunk 主干，一般在此开发，只有一个主干
branches 分支，做不同用途，存在多个子分支
tags 分支，里程碑，存在多个里程碑，比如 v1, v2, …

在 trunk 中创建 aaa.txt 文件，并提交到版本库。

创建分支

右键 trunk --> Branch/tag
To path 输入 /branches/test-branch
表示创建一个 test-branch 分支。

进入 branches 发现还是空的，需要对 branches 做update操作才会看到 test-branch，因为创建分支也会记录一个版本号，你可以通过 show log 证明这一点。

以同样的方式创建 pro-branch 分支。

Linux命令类似于：

svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Creating a private branch of /calc/trunk."

创建 tag 的方式和 branch 的方式一样，只是目录不一样。tag在项目开发中使用的很少，除非是做开源软件。

合并分支

将一个分支的代码合并到另一个分支。

在 trunk 中创建 bbb.txt 文件，并提交到版本库。
右键 test-branch --> Merge
选择 Merge a range of reversion 。
URL to merge from 输入 file:///D:/dev/repo/test/trunk
选择 all reversions 。

merge 完成后 test-branch 就多出了 bbb.txt，右键 test-branch 提交到版本库。

在合并的过程中难免会有冲突，选择 resolve all later ，然后手动处理掉，再提交。

分支切换

svn switch 切换当前 working copy 的内容为指定的分支项目。这个功能在svn用的少，而在gitlab用的很多，因为在svn中每一个分支都有自己的working copy也就是目录，直接进如目录就行了，没必要切来切去。

开发环境，测试环境，生产环境

1、我们在 trunk 下开发，一个功能开发完毕即可commit。

2、将 trunk 合并到 test-branch，并提交；来到测试服务器，对 test-branch 进行update操作，于是开始测试 test-branch 分支，所以此时你使用的 test-branch 代码来跑。

3、如果测试出了Bug，重复1，2的操作；如果测试通过，我们将 test-branch 合并到 pro-branch，并提交；来到线上服务器，对 pro-branch 进行update操作，所以此时你使用的 test-branch 代码来跑。为什么不直接将 trunk 合并到 pro-branch，因为此时你可能正在开发别的功能。

再多人开发模式下，每个人会有一个branch，然后每个人的分支和trunk分支在不停的进行merge操作，为了减少冲突的概率，你需要提高merge的频率。

总结与注意

通过上面的介绍，你应该有个概念，那就是svn的每个分支就是一个项目，并且互相感知不到彼此的存在，完全根据每个项目的URL来实现分支的操作，从这一点来看，分支项目具体放在哪里完全由你决定。

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的合并，有几点需要注意：
1、TortoiseSVN的合并发生在本地，也即你的working copy中，你无需过多担心会对repository中的代码造成影响。
2、不管是从trunk合并到branch还是最终从branch合并回trunk，在每次合并前最好先update，然后将本地的修改先全部commit，保护好现场，万一合并不理想随时都可以revert。
3、合并完成后看是否能正确编译，然后测试验证，最后将合并后的改动提交到repository。