这篇教程不是救急方案。如果你在寻找救急方案,我建议你现在就点击浏览器的返回按钮。如果你想详细了解如何使用 SourceTree 解决 git 中的合并冲突,本教程会教你怎么做。深吸一口气!
很简单。当 git 不知道如何自动合并某个文件的多处改动的时候,就会引发冲突。即使有时合并方式是非常显而易见的。通常会发生在多人修改同一个文件时。
具体来说,git 中的合并冲突会发生在这些场景中:
我们会讨论这两种场景,以及可能导致合并冲突的其他场景。
合并冲突会先显示这条消息
发生这种情况时不要惊慌。这只是一个临时状态。即使你在合并的时候搞错了,也总是可以重置分支(如下图显示)以返回合并开始之前的状态。
现在点击 “Working Copy” 分区。你会看到受合并冲突影响的文件都在左侧有个感叹号。
现在有多种方式可以解决冲突,按个看一遍
这是修复 git 中的合并冲突最简单的方式。如果你右击任意有冲突的文件,它会在 “Resolve Conflicts” 下面显示两个选项。
“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 里面的视图可能不够用。对于这些情况,我推荐下面的两种方法。
我最喜欢这种方法。最开始有点难以掌握,但熟悉后就会成为解决 git 中的合并冲突最灵活的方法。
在你最喜欢的编辑器或 IDE 中打开冲突的文件。
确保删除掉具有特殊字符和分支名称 /HEAD 的那几行。进行更改直到对文件的最终状态感到满意。保存文件。
这是我手动编辑文件后的最终版本。
回到 SourceTree,在 “unstaged files” 区域里选择冲突的文件。拖到上面的 “staged files” 区域里面。或者也可以右击文件,然后选择 Resolve Conflicts > Mark Resolved。
现在可以进行提交了,冲突已经被手动解决了。耶!
还可以启动外部合并工具来解决冲突。它们通常会让你选择某一个版本,或者两者都选。目前 SourceTree 好像并不支持这个功能。
只要没有提交,就可以从顶部菜单中选择 “Reset All”。然后就可以重新开始分支合并操作,一切都将从头来过。