在之前的正常合并中，我们都是通过将一个修改的子分支合并到我们没有修改的主分支里面，此时我们称这个过程为正常合并
假设此时我们将一个修改的子分支合并到我们修改了的主分支里面，那么此时便有可能发生冲突合并。
冲突合并产生的原因？
答：是两个分支在同一个文件的同一个位置有两套完全不同的修改。Git 无法替我们决定使用哪一个。必须人为决定新代码内容。
那么此时我们来模拟下冲突合并发生的过程以及解决的办法：
1：首先我们在master分支下使用vim 文件名修改我们的hello.txt文件：修改如下所示
此时我们在倒数第二行加上我们的master test
修改完成后，此时我们还是按照之前介绍的步骤将我们修改后的hello.txt文件上传到master分支下的本地库，具题步骤不做详述，直接上截图：
2：完毕后此时我们切换到我们的hot-fix分支下去修改我们hot-fix分支下的hello.txt文件，过程如下所示：
此时我们在倒数第一行加上我们的hot-fix test,完成对hot-fix分支下的hello.txt文件的修改，继续重复之前的操作，将修改后的hello.txt文件上传到hot-fix分支下的本地库
3：此时完成对hot-fix分支下的hello.txt文件的修改以及上传后，此时我们继续回到我们的master主分支下，进行我们分支的合并
输入git merge hot-fix后此时便会出现我们的分支冲突，原因是我们的master分支和我们的hot-fix分支此时都对我们的hello.txt文件进行了修改，导致当我们将hot-fix分支合并到我们master分支的时候，git不知道使用两个分支的哪一套针对hello.txt文件的修改方案，那么此时便会发生分支冲突。
如下图所示：会出现一个conflict英文字母以及当出现冲突后，我们括号内的字母不再是master,而是master|MERGING，表明一直在合并中，但是没有成功。
并且此时我们输入git status命令后我们会发现此时的hello.txt文件是没有合并成功的：both modified hello.txt表示两个分支都修改了hello.txt文件，此时git不敢自动合并分支了，只能我们人为手动合并分支代码了。
4：为了解决我们的冲突合并的问题，此时就需要我们去人为决定新代码的内容：
第一步：此时首先使用vim hello.txt命令先手动打开我们的文件，此时我们会发现跟之前有一些不同之处：
此时我们会发现三个特殊的符号：
<<<<<<>>>>>>中间为要合并进master分支的代码
第二步：为了解决我么分支冲突的问题，此时需要人工修改我们的代码，之前我们修改了hot-fix分支下的hello.txt文件中的最后一行，修改了master分支下的hello.txt文件的倒数第二行，此时我们要将hot-fix分支合并到master分支下，那么我们的hello.txt文件此时倒数两行都应该要被修改，那么此时我们就按照我们预期的效果来进行人工修改，删除特殊符号，决定要使用的内容即可：
修改完成后，输入:wq保存后，此时我们仍需要将我们人为修改的hello.txt文件上传到我们的暂存区以及我们的本地库中
第三步：将我们人工修改后的hello.txt文件上传到暂存区：如下图所示：我们会发现此时我们的冲突合并还没有解决，因为此时括号内还是有MERGING
第四步：此时继续将修改后的hello.txt文件提交到本地库中去,但是此处需要注意的是之前我们将文件提交到本地库的命令为git commit -m "日志信息" 文件名，
但是此处为了解决我们分支的合并冲突，此时不能加文件名，这样才能解决我们的冲突合并：如下图所示：
1：假设此时我们带上了文件名的话：会报一个致命的错误：
2：假设此时不带上我们的文件名的话，此时便解决了我们的冲突合并，并且此时我们括号内的master|MERGING变成了master,说明此时成功了。
第五步：使用vim hello.txt命令查看我们的hello.txt文件内容：发现此时分支代码合并成功，是我们所预期的效果。
注意：此时我们合并的代码只是覆盖了原本我们主分支master下的hello.txt文件内的内容，但是我们子分支hot-fix分支下的内容并没有发生改变，如下图所示，我们可以看到我们的子分支hot-fix中的hello.txt文件内容并没有发生改变：
