SVN合并时候的冲突

1.先在主干上创建一个test.txt文件，提交。

2.拉一个分支。

此时，主线、分支两边代码应该是一模一样的。

主线：

 分支：

这时候，主线进行开发：

修改了test.txt：

在3333后面添加了3333test，

在4444后面添加了4444test，

在文件最后添加了7777test，并且提交。（如图）

新增了computer.txt文件

新增了user.txt文件

同样的，在分支也进行开发：

分支修改test.txt文件

新增computer文件

新增user文件

这时候将主干、分支修改的代码都提交。

提交主干

提交分支 

再对主干代码进行合并分支的操作，会出现如下冲突：

其中提示，

test.txt文件冲突（两边修改了同一行代码）

computer.txt和user.txt树冲突（都新增了文件）

解决文件冲突：

左上角（Theirs）：代表合并版本的样子

右上角（Mine）：代表本地版本的样子

下方（Merged）：代表合并后的样子

 橙色部分：代表原来的代码（参考用）

 亮黄色部分：代表svn自动合并好的部分（自动解决）

 红色部分：代表两边代码冲突的部分（需要人工解决）

ps：如果只看Theirs或者Mine，对比上面分支、主干提交时候的截图，可以发现

除开橙色行、灰色行，对应提交后的最新部分的代码。而橙色行则是该次提交之前，所在行代码的原来样子。

合并的时候，一般是框选（Merged部分），我们先观察Merged部分的第4行。

通过上面主线、分支的提交，我们可以知道，我们在主线上第4行添加了4444test，在分支上第4行添加了4444branch，这时候我们就需要进行合并后的代码判断，是否需要主干、分支代码都保留，还是只保留主干、只保留分支。

右键，Use text block分别有四个选项

1.用Theirs（用分支）

2.用Mine（主干）

3.先Mine后Theirs（先主干，后分支）

4.先Theirs后Mine（先分支，后主干）

我们这边先以3为例，将主干分支代码保留。

然后我们再对Megred的8、9行进行处理，通过对比可以发现，我们在主干上最后添加了7777test，分支最后添加了8888test，这里因为是在末尾行，svn自行判断为是更改了最后一行，而不是在原来的最后一行的基础上添加了一行，所以svn认为的改动是两行改动。

如果这时候我们选择3.先Mine后Theirs，会出现下图情况，发现6666的那段代码重复了两次

这时候就需要人工仔细的排查了，是否需要两次的6666代码，我们这里不需要，所以在Merged中，我们删去第11行的6666，得到如下图的最终合并文件。（看到橙黄色不要担心，Theirs、Mine、Merged中橙黄色没有行号的代码只起到参考作用，不会存在于文件中）

解决树冲突：

树冲突的解决相对单一，只能选择Accept current working copt state (mark as resolved) ，即接受当前工作空间的副本（并标记为解决）。点击后，就解决了冲突。

这时候我们去合并后的内容中看这个树冲突的文件，发现依然是合并前的文件。

 所以可以得出结论，树冲突并不会更改本地的文件，他只会告诉你冲突，这时候需要人工的去排查代码。

ps：树冲突不仅限于新增*新增，也可以是  新增*修改、新增*删除、修改*删除

当所有的冲突解决完毕后，就可以提交主干代码啦！

另外，颜色部分的内容可参考下面博主的文章

http://blog.csdn.net/daigualu/article/details/68936061?ref=myread

另外命令行参考这里：

http://www.jianshu.com/p/e3cc83ca512d