文章目录
- 3.4.12 合并分支代码
- TortoiseSVN有2种合并方式
- 演示场景1：（合并一个版本范围 Merge a range of revisions）
- 演示场景2：（合并两个不同的树 Merge two different trees），不设置主分支版本
- 演示场景3：（合并两个不同的树 Merge two different trees），设置主分支版本
- 结论总结：
3.4.12 合并分支代码
需求：这里为了演练一种场景，我主分支trunk_V01创建一个新的开发分支trunk_V02，然后主分支和新分支一起开发不同通能，最后我要把trunk_V02新分支合并到主分支trunk_V01上，要求是主分支新创建的文件要存在，新分支trunk_V02新创建的文件也要存在，冲突的相同文件名内容解决冲突即可。
说明：主分支trunk_V01里面只有一个文件text.txt文件，内容如图，然后将依照当前主分支创建新分支命名叫trunk_V02
接下来模拟两个分支不同开发，主分支创建新文件trunk_V01_01.txt，并且修改text.txt内容，然后新分支trunk_V02创建新文件trunk_V01_02.txt，并且修改text.txt内容，项目目录如图1，主分支如图2，新分支如图3
TortoiseSVN有2种合并方式
TortoiseSVN有2种合并方式：
合并一个版本范围 Merge a range of revisions：此类型应用最为广泛，主要是把分支中的修改合并到主干上来。在主干上点击右键选择合并，然后选择合并类型：合并一个范围的版本。合并的源URL填写的是要合并的分支的URL，待合并的版本范围如果为空，则指的是合并分支上所有的版本，即自从分支创建以来到分支当前最新版本的所有演变。如果只是选择其中一个版本，或者几个版本，那么就表示只是将制定的n个版本的变化合并到主干上。如果只是选择其中一个版本，那么表示只是选择那个版本的修改，之前或之后的修改将不被采纳。合并两个不同的树 Merge two different trees：此类型与前1种类型不同，第一种类型可以选择分支合并的版本，主干不能选择版本；而这种类型则是无论是主干还是分支都可以选择合并的版本，即可以选择过去的一个主干版本与分支的某个版本进行合并。合并的时候以选择的分支版本为主，如果选择的主干版本与分支版本有不同的地方，合并时主干部分将被放弃。起始URL：选择主干目录的URL(应当和当前工作副本的URL一致，这个是所谓的合并点)。结束URL：选择要合并的分支的URL。起始和结束的版本：一般起始版本应当找到最后一次同步时的版本，如果从没有同步过(第一次合并)，则选择创建分支时的版本，结束版本一般是最新版本，如果你不想将某些内容合并进主干的话，也可以选择一个合并点。
演示场景1：（合并一个版本范围 Merge a range of revisions）
演示场景1：（合并一个版本范围 Merge a range of revisions）
第一步，在文件夹trunk_V01点击右键“合并”
选择第一种合并类型
合并源url选择trunk_V01的地址，将要合并的修改版本范围选择所有版本
打开合并后的文件夹查看，最终效果是：text.txt冲突了但解决了冲突之后拥有全新的代码，主分支trunk_V01新创建的文件trunk_V01_01.txt依然存在，新分支trunk_V02新创建的文件trunk_V02_01.txt也存在。（即：最终效果正确，就是我们想要的）
演示场景2：（合并两个不同的树 Merge two different trees），不设置主分支版本
演示场景2：（合并两个不同的树 Merge two different trees），不设置主分支版本
重复上面的第一步选择第2种合并类型
选择起始、结束url，版本都用最新的版本
打开合并后的文件夹查看，最终效果是：text.txt冲突了但解决了冲突之后拥有全新的代码，但主分支trunk_V01新创建的文件trunk_V01_01.txt被删除了，新分支trunk_V02新创建的文件trunk_V02_01.txt存在。（即：最终效果不正确，新分支的确实都存在，但主分支新创建的文件全丢了）
问题：思考为啥这种方式对导致主分支新创建的文件丢失？
答案：因为创建新分支trunk_V02的时候主版本只有text.txt文件，而trunk_V01_01.txt是主分支后面新开发创建的，在合并的时候由于主分支采用最新版本情况下导致合并的时候不认识，所以导致合并会删除它。而场景3由于设置了主分支版本号，就相当于合并代码的时候是从主分支在最开始刚创建新分支的时候版本进行合并的，因此主分支新创建的文件trunk_V01_01.txt会被保留。
（我用大白话再表述一遍：当前主分支trunk_V01版本号为1的时候，主分支trunk_V01只有text.txt文件，这时候创建的新分支trunk_V02版本号为2，这时候分别开发提交自己代码，主分支trunk_V01新创建trunk_V01_01.txt文件并提交此时版本号为3，新分支trunk_V02也新创建trunk_V02_01.txt文件并提交此时版本号为4，此时再进行合并代码的时候由于新分支trunk_V02是从主分支trunk_V01版本号为1时创建过来的，所以SVN只认识主分支上版本号为1之前的所有改动，即只认识text.txt文件，而后来的trunk_V01_01.txt文件是主分支trunk_V01新创建的，所以SVN不认识，这就导致合并的时候给它删了。即：所谓的分支版本合并，就是把两个分支设置版本号之前的所有改动给统一合并代码。）
演示场景3：（合并两个不同的树 Merge two different trees），设置主分支版本
演示场景3：（合并两个不同的树 Merge two different trees），设置主分支版本
重复上面的前两步主分支版本设置为创建新分支trunk_V02时候的版本，具体方法可查看“版本分支图”，选中新分支trunk_V02文件夹点击右键“版本分支图”查看，可以查看起始版本是116，说明主分支当时的版本是115（即在主分支115版本时进行创建了新分支trunk_V02，所以第三步这里输入115）
选择起始、结束url，主分支版本进行设置，新分支采用最新的版本
打开合并后的文件夹查看，最终效果是：text.txt冲突了但解决了冲突之后拥有全新的代码，主分支trunk_V01新创建的文件trunk_V01_01.txt依然存在，新分支trunk_V02新创建的文件trunk_V02_01.txt也存在。（即：最终效果正确，就是我们想要的）
结论总结：
结论总结：
结论1：“合并一个版本范围”方式是默认合并方式。
结论2：“合并一个版本范围”方式相当于往主分支最新版本上面合代码，因为它不像第二种方式可以指定主分支版本号。
结论3：“合并两个不同树“方式相当于更细化的合并操作，可以分别指派主分支和新分支的版本号进行两两合并，效果更自由。
结论4：“合并一个版本范围”方式和“合并两个不同树且设置主分支版本”方式效果是一样的。
结论5：“合并两个不同树且不设置主分支版本”方式，那么最终的效果就是：如果选择的主干版本与分支版本有不同的地方，合并时主干部分将被放弃。（这就是为什么演练场景2时发现主分支丢文件了，被删除了。）
