使用 SourceTree 修复 git 的合并冲突
这篇教程不是救急方案。如果你在寻找救急方案，我建议你现在就点击浏览器的返回按钮。如果你想详细了解如何使用 SourceTree 解决 git 中的合并冲突，本教程会教你怎么做。深吸一口气！
git 中为什么会出现合并冲突？
很简单。当 git 不知道如何自动合并某个文件的多处改动的时候，就会引发冲突。即使有时合并方式是非常显而易见的。通常会发生在多人修改同一个文件时。
具体来说，git 中的合并冲突会发生在这些场景中：
- 合并两个分支的时候。
- 回滚区块的时候（我最喜欢的功能）
我们会讨论这两种场景，以及可能导致合并冲突的其他场景。
开始吧！
合并冲突会先显示这条消息
发生这种情况时不要惊慌。这只是一个临时状态。即使你在合并的时候搞错了，也总是可以重置分支（如下图显示）以返回合并开始之前的状态。
现在点击 “Working Copy” 分区。你会看到受合并冲突影响的文件都在左侧有个感叹号。
现在有多种方式可以解决冲突，按个看一遍
使用 SourceTree 解决 git 中的合并冲突
1）使用 “mine” 或 “theirs” 来解决
这是修复 git 中的合并冲突最简单的方式。如果你右击任意有冲突的文件，它会在 “Resolve Conflicts” 下面显示两个选项。
- Resolve using ‘Mine’
- Resolve using ‘Theirs’
“Mine” 表示冲突文件在你当前分支上的内容。“Theirs” 表示冲突文件在传入分支上的内容——尝试合并到当前分支的那个分支。
注意：如果是回滚操作，“Theirs” 表示冲突文件在回滚区块上的内容。
所以，通过选择 “Mine” 或 “Theirs”，你只是指示 git 丢弃其中一个版本，并使用另外那个版本。
如何决定选择哪个版本？
下个问题你可能要问，我怎么知道该选择哪个版本——“Mine” 还是 “Theirs”？
大部分情况下，你应该已经知道怎么做，因为你知道每个分支中提交的内容。那就可以跳过这个部分。但如果不是，也不要担心。选择冲突的文件，然后可以在右侧看到文件的内容。
仔细注意这里的模式，你会在每个有合并冲突的文件中看到它。
<<<<<<< HEAD
...content on current branch...
=======
...content on incoming branch...
>>>>>>> change (or the name of whatever your incoming branch is)
你可以把 HEAD 看作当前分支。在上面的例子里，就是 “master” 分支。
从 <<<<<<< HEAD 到 ======= 那行之间的就是当前分支上的内容。从 ======= 到 >>>>>>> 你的传入分支名之间的就是传入分支上的内容（在上面的例子中就是 “change”）
还要记住在用 SourceTree 读取文件的时候，可以跳过红色标注的行，因为它们已经被删了。绿色标注的那些是新添加的。
你可能正在处理一个巨大的文件，在多个部分有多个冲突，那么 SourceTree 里面的视图可能不够用。对于这些情况，我推荐下面的两种方法。
2）使用手动编辑方法解决
我最喜欢这种方法。最开始有点难以掌握，但熟悉后就会成为解决 git 中的合并冲突最灵活的方法。
在你最喜欢的编辑器或 IDE 中打开冲突的文件。
确保删除掉具有特殊字符和分支名称 /HEAD 的那几行。进行更改直到对文件的最终状态感到满意。保存文件。
这是我手动编辑文件后的最终版本。
回到 SourceTree，在 “unstaged files” 区域里选择冲突的文件。拖到上面的 “staged files” 区域里面。或者也可以右击文件，然后选择 Resolve Conflicts > Mark Resolved。
现在可以进行提交了，冲突已经被手动解决了。耶！
3）使用外部合并工具解决
还可以启动外部合并工具来解决冲突。它们通常会让你选择某一个版本，或者两者都选。目前 SourceTree 好像并不支持这个功能。
如果在合并过程中搞错了怎么办？
只要没有提交，就可以从顶部菜单中选择 “Reset All”。然后就可以重新开始分支合并操作，一切都将从头来过。
如果还有问题的话，在下方评论，希望能帮助到你。
