合并冲突
可是，在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。
为了演示这问题，创建一个新的分支 dev1 ，并切换至目标分支，我们可以使用 git checkout -b dev1 一步完成创建并切换的动作，示例如下：
$ git checkout -b dev1
Switched to a new branch 'dev1'$ git branch
* dev1master
在 dev1 分支下修改 ReadMe 文件，更改文件内容如下，并进行一次提交，如：
$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch # 将aaa该为bbb$ git add.
$ git commit -m"modify ReadMe"
[dev1 0854245] modify ReadMe1 file changed, 1 insertion(+), 1 deletion(-)
切换至 master 分支，观察 ReadMe 文件内容：
$ git checkout master
Switched to branch'master'$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch
我们发现，切回来之后，文件内容变成了老的版本，这种现象很正常，我们现在也完全能理解。
此时在 master 分支上，我们对 ReadMe 文件再进行一次修改，并进行提交，如下：
$ git branch
dev1
* master$ vim ReadMe
$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write ccc for new branch$ git add.
$ git commit -m"modify ReadMe"
[master 1c10f6d] modify ReadMe1 file changed, 1 insertion(+), 1 deletion(-)
现在，master 分支和 dev1 分支各自都分别有新的提交，变成了这样：
这种情况下，Git 只能试图把各自的修改合并起来，但这种合并就可能会有冲突，如下所示：
$ git merge dev1
Auto - merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.$ git status
On branch master
You have unmerged paths.(fix conflicts and run "git commit")(use "git merge --abort" to abort the merge)
Unmerged paths:(use "git add <file>..." to mark resolution)both modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")
发现 ReadMe 文件有冲突后，可以直接查看文件内容，要说的是 Git 会用 <<<<<<<，=======，>>>>>>> 来标记出不同分支的冲突内容，如下所示：
$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
<<<<<<< HEAD
write ccc for new branch
=======
write bbb for new branch
>>>>>>> dev1
此时我们必须要手动调整冲突代码，并需要再次提交修正后的结果！！（再次提交很重要，切勿忘记）
$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch$ git add.
$ git commit -m"merge ReadMe"
[master 2976afc] merge ReadMe
到这里冲突就解决完成，此时的状态变成了
用带参数的 git log 也可以看到分支的合并情况，具体大家可以自行搜索 git log 的用法:
$ git log --graph --pretty=oneline --abbrev-commit
* 2976afc (HEAD -> master) merge ReadMe
|\
| * c59f4d1 (dev1) modify ReadMe
* | c10f6d0 modify ReadMe
|/
最后，不要忘记 dev1 分支使用完毕后就可以删除了：
$ git branch
* master$ git branch -d dev1
Deleted branch dev1 (was c59f4d1).
分支管理策略
通常合并分支时，如果可能，Git 会采用 Fast forward 模式。还记得如果我们采用 Fast forward 模式之后，形成的合并结果是什么样呢？回顾一下
在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是从哪个分支过来的。
但在合并时如果发生了冲突，我们还是正常提交解决冲突问题，会再进行一次新的提交，得到的最终状态为：
那么就不是 Fast forward 模式了，这样的好处是，从分支历史上就可以看出分支信息。
例如我们现在已经删除了在合并冲突部分创建的 dev1 分支，但依旧能看到 master 其实是由其他分支合并得来的。
$ git log --graph --pretty=oneline --abbrev-commit
* 2976afc (HEAD -> master) merge ReadMe
|\
| * c59f4d1 modify ReadMe
* | c10f6d0 modify ReadMe
|/
Git 支持我们强制禁用 Fast forward 模式，那么就会在 merge 时生成一个新的 commit ，这样，从分支历史上就可以看出分支信息。
下面我们实战一下 --no-ff 方式的 git merge 。首先，创建新的分支 dev2 ，并切换至新的分支：
$ git checkout -b dev2
Switched to a new branch 'dev2'
修改 ReadMe 文件，并提交一个新的 commit：
$ cat ReadMe
hello bit
hello world
hello git
hello version1
hello version2
hello version3
write bbb for new branch$ git add.
$ git commit -m"modify ReadMe"
[dev2 41b82f7] modify ReadMe1 file changed, 1 insertion(+)
切回 master 分支，开始合并：
$ git checkout master
Switched to branch'master'$ git merge --no-ff -m "merge with --no-ff" dev2
Merge made by the 'recursive' strategy.
ReadMe | 1 +
1 file changed, 1 insertion(+)$ cat ReadMe
hello bit
hello world
hello git
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
请注意 --no-ff 参数，表示禁用 Fast forward 模式。禁用 Fast forward 模式后合并会创建一个新的 commit ，所以加上 -m 参数，把 merge 信息写进去。
合并后，查看分支历史：
$ git log --graph --pretty=oneline --abbrev-commit
* 5bde1b4 (HEAD -> master) merge with --no-ff
|\
| * 41b82f7 (dev2) modify ReadMe
* | c10f6d0 modify ReadMe
|/
可以看到，不使用 Fast forward 模式，merge 后像这样：
所以在合并分支时，加上 --no-ff 参数就可以保留分支信息，合并后的历史有分支，能看出来曾经做过合并，而 fast forward 合并就看不出来曾经做过合并。