版本控制系统就是负责管理来自于多个提交者（通常是开发者）之间的提交的。有时候多个开发者可能会编辑同一部分内容。一旦开发者A编辑了开发者B正在编辑的内容，冲突就会产生。为了降低冲突发生的概率，开发者们会在独立的分支内开展工作。git merge命令的主要职责就在于整合不同分支并且解决冲突。

理解merge冲突

合并和冲突是使用Git过程中的常见场景。在其他版本控制工具中冲突可能会非常浪费时间。Git让合并变得更加简单。大多数时候，Git会自行弄清楚如何自动的整合新变化。

冲突一般来自于两个不同的开发者改变了同一个文件中的同一行内容，或者一个开发者删除了另一个开发者正在修改的文件。在这类场景下，Git无法自动确定谁的改动是应该采纳的。冲突发生时只会影响到执行合并操作的开发者，而其他团队成员则不会受到任何影响。Git会对发生冲突的文件进行标记并停止合并进程。接下来就需要开发者自行进行冲突处理。

Merge 冲突的类型

进入冲突状态发生在合并过程中的两个时间点。一个是开始进行合并时，另一个是在合并过程中。接下来的内容分别关于如何解决这两种不同场景。

合并开始时的冲突

当工作目录下或者暂存区内的文件含有变更时，Git会中断合并操作。之所以Git会如此操作，是因为Git认为这些未提交的变更会被合并操作覆盖掉。这种情况发生时，并不是因为改变会与其他开发者的提交产生冲突，而是合并本身会与本地的修改产生冲突。此时需要使用git stash, git checkout,git commit或者git reset 命令使得本地仓库处于稳定状态。合并操作开始时的失败会在命令行提示如下错误信息：

error: Entry '<fileName>' not uptodate. Cannot merge. (Changes in working directory)

合并进行时的冲突

合并过程中发生的冲突意味着你的本地分支与进行合并的分支产生了冲突。也就是说你本地的代码与其他开发者的代码产生了冲突。Git会尽量合并不同分支的文件，但如果真正产生冲突仍然会将手动合并的任务交给你来处理。这种场景下Git会在命令行留下如下的错误信息：

error: Entry '<fileName>' would be overwritten by merge. Cannot merge. (Changes in staging area)

创造一个合并冲突

为了真正的了解合并冲突，下面的内容将会手动模拟创建一个冲突并且在稍后来查看和解决这个冲突。下面的代码需要您使用*nix系统的命令行Git工具，以便创建这个模拟冲突。

$ mkdir git-merge-test
$ cd git-merge-test
$ git init .
$ echo "this is some content to mess with" > merge.txt
$ git add merge.txt
$ git commit -am"we are commiting the inital content"
[main (root-commit) d48e74c] we are commiting the inital content
1 file changed, 1 insertion(+)
create mode 100644 merge.txt

上面的代码实际上做了如下几件事情：

• 创建了一个叫做git-merge-test的目录，进入这个目录，然后初始化一个Git仓库
• 创建一个随便含有什么内容的merge.txt文件
• 添加merge.txt文件到仓库中然后进行提交

此时我们就拥有了一个新Git仓库，其中含有main分支，和一个有内容的merge.txt的文件。接下来，让我们创建另外一个分支，作为产生冲突的分支。

$ git checkout -b new_branch_to_merge_later
$ echo "totally different content to merge later" > merge.txt
$ git commit -am"edited the content of merge.txt to cause a conflict"
[new_branch_to_merge_later 6282319] edited the content of merge.txt to cause a conflict
1 file changed, 1 insertion(+), 1 deletion(-)

执行如上命令会产生下面的效果：

• 创建并检出名为new_branch_merge_later的分支
• 覆盖merge.txt文件中的内容
• 提交新的内容

在这个新创建的分支new_branch_to_merge_later中，我们提交了重写的merge.txt的内容

git checkout main
Switched to branch 'main'
echo "content to append" >> merge.txt
git commit -am"appended content to merge.txt"
[main 24fbe3c] appended content to merge.tx
1 file changed, 1 insertion(+)

上面的一系列命令首先检出了main分支，然后向merge.txt文件中追加了新的内容，然后提交。到此为止我们的仓库中的分支状况为：两个分支，main和new_branch_to_merge_later分别有两个新的提交。然后我们来试试执行git merge new_branch_to_merge_later命令会如何~

$ git merge new_branch_to_merge_later
Auto-merging merge.txt
CONFLICT (content): Merge conflict in merge.txt
Automatic merge failed; fix conflicts and then commit the result.

哐叽，果然冲突出现了。感谢Git。

如何辨认冲突内容

正如我们上面的示例所演示的一般，Git会在命令行中输出一些描述信息，以便让我们知道有冲突发生。接下来我们可以执行git status命令更加深入的检视冲突的详情。

$ git status
On branch main
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:   merge.txt

git status命令的输出显示了由于冲突而没有成功合并的文件路径。果不其然merge.txt文件出现在合并双方都进行修改的那一状态栏中。接下来就需要打开文件看看具体发生了什么不能合并的修改。

$ cat merge.txt
<<<<<<< HEAD
this is some content to mess with
content to append
=======
totally different content to merge later
>>>>>>> new_branch_to_merge_later

上面的命令中我们使用cat命令来显示merge.txt文件中的内容。可以看到一些奇怪的东西

• <<<<<<< HEAD
• =======
• >>>>>>> new_branch_to_merge_later

可以把这些行的内容看作是“冲突的分界线”。======的那一行是冲突发生的正中间。在冲突中间和<<<<<< HEAD之间的那些行表示的是存在于当前分支——也就是当前仓库中HEAD指针指向的那个分支——的内容。相对应的在冲突中间到>>>>>>行之间的内容则是new_branch_to_merge_later分支中的内容。

如何使用命令行解决冲突

最直接的解决冲突的方式就是修改冲突的文件内容。使用你最常用的编辑器打开merge.txt文件。在本例中，我们就只是简单的把没有意义的冲突分界线删掉。然后修改之后的merge.txt文件的内容看起来就是下面这个样子：

this is some content to mess with
content to append
totally different content to merge later

一旦修改完成冲突文件，就是用git add merge.txt命令来暂存新的合并内容。敲定最终合并的方式也很简单，通过下面的命令执行一次commit即可：

git commit -m "merged and resolved the conflict in merge.txt"

这时候Git会认为冲突已经解决，然后创建一个新的合并提交来完成整个合并。

可以用来解决合并冲突的Git命令

通用工具

git status

status命令是使用Git过程中的常见命令，尤其是在merge过程中，它能帮助你辨别哪些文件处于冲突状态。

git log --merge

向git log命令传递--merge参数，会将此次合并中造成冲突的来自于两个分支中的具体提交列出来。

git diff

diff有助于找到仓库或者文件在不同状态之间的异同。这通常可以用来预测或者阻止可能产生冲突的合并。

启动合并时就发生冲突场景下的常用工具

git checkout

checkout可以用来撤销对于文件或者分支的修改

git reset --mixed

reset用于撤销当前工作目录或者已经进入暂存区的变更

合并过程中发生冲突场景下的常用工具

git merge --abort

执行git merge命令时带上--abort选项将会退出这次合并，并且恢复到当前分支在进行合并之前的状态

git reset

git reset用于在合并冲突发生时，将一个文件重置到你所知道应该是正常状态的那个版本

总结

合并冲突可以是一次令人害怕的经历。幸运的是，Git提供了强大的工具来帮助寻找和解决冲突。Git可以处理大多数场景，进行自动合并。在Git中一般造成冲突的场景无非是两个独立的分支对同一个文件进行了修改，或者是当一个分支中删除了某个文件，而另一个分支在同一个文件上进行了修改。冲突通常发生在团队协作的环境中。

有许多用于解决合并冲突的工具。本文中我们讨论了很多Git提供的命令行工具。此外还有很多第三方的工具提供冲突解决工具。