解决 Git 冲突的 14 个建议和工具

(点击 上方蓝字 ，快速关注我们)

译文：伯乐在线专栏作者 - 青劲草

英文：Nicola Paolucci

如有好文章投稿，请点击 → 这里了解详情

如需转载，发送「转载」二字查看说明

Git 非常善于合并代码。代码的合并在本地完成，快速而且灵活。正常情况下每次从不同分支合并内容时，冲突有可能会发生。通常解决冲突很简单，就如同知道（如何）选择（保留）重要的更改一样，而有时解决冲突则需要额外的工作。

每个开发者对于解决冲突有不同的偏好。不久前，一位叫丹·史蒂文斯的同事用内部软件 Questions for Confluence 询问了大家是如何做的。

收集到的回答和看法比 Atlassian 之墙有更大的吸引力。下面是我们用多种方式解决 Git 冲突的详尽描述，希望它能提供一些可以去尝试的想法，并且融入到你日常编程习惯中。

（ Atlassian 之墙是指 Atlassian 公司让客户将意见和反馈贴在墙上，可以参考这幅图(http://atlassian.wpengine.netdna-cdn.com/wp-content/uploads/ww-customers-600x450.jpg)，译者注）

通用设置建议

为了设置 Git 使其能正确合并，我们先开始做一些简单的配置。

1. 设置建议

当遇到冲突时，可以在命令行或者其他可视化工具中输入“git mergetool”来初始化合并活动。在“.gitconfig”中用“merge.tool”变量来设置 Git 中自己喜欢的冲突解决软件，比如用 KDiff3 的可能会这样填写”.gitconfig” 的 merge 部分：

[ merge ]

tool = "kdiff3"

上面的语句等价于在命令行输入以下命令：

git config --global merge.tool kdiff3

2. 在冲突标记中显示（分支）共同的祖先

用下面的设置来改进冲突标记使其也显示（分支）共同祖先（感谢罗宾·斯托克和休·吉登斯）：

git config --global merge.conflictstyle diff3

这个设置命令新添加一部分标记||||||| 从而给冲突加了注释，这样可以看到冲突行在有问题的两个分支的共同祖先处是什么状态。

3. 合并时使用“耐心”算法

如果文件内容很长（比如一个 XML文件）、冲突很多或者两个版本很不一致时，试着用下面的命令再次合并：

git merge --strategy-option=patience

“耐心”算法的结果应该可以更好地协调一些函数中或者标记中没有配对的括号，具体算法细节可以参考 Stack Overflow 上的一个回答(http://stackoverflow.com/questions/4045017/what-is-git-diff-patience-for)。

4. 当你需要单个文件的历史信息时

除非使用像 SourceTree 一样的可视化工具来弄清到底对一个文件做过什么，不然你可以使用：

git log --merge --decorate --source -p path/to/file/you/care/about

手动解决冲突

处理合并问题主要有两类做法：有些开发者喜欢偏底层处理，因而手工操作处理冲突标记，而有些则偏好可视化工具来辅助（解决冲突）。两种方式都能极其有效地解决冲突。

5. 处理过程示例

有几个同事分享了他们手动处理的过程，比如詹森·欣奇描述了他的处理流程：

• 从手头的合并开始：

git merge the / other / branch

git status

• 看下有多少文件冲突。

• 对每个冲突文件：

- 在编辑器中打开文件（比如 IntelliJ 或 Vim ）

- 看看每个被冲突标记（“>>>>”和“

- 看看（被冲突标记的区块）是否有意义，每个作者的意图是什么，如果能弄清楚就解决掉。

- 如果冲突标记无法理解，通常是这些文件改动很大，运行下面的命令：

git diff HEAD .. .the / other / branch -- path / to / conflicting / file

git diff the / other / branch .. .HEAD -- path / to / conflicting / file

这样做是为了看哪边改动较小

• 通常下面的命令：

git log - p HEAD . .the / other / branch -- path / to / conflicting / file

git log - p the / other / branch . .HEAD -- path / to / conflicting / file

能帮助理解另一边改动了什么。

• 回溯文件到改动最大的一边：

git checkout the/other/branch -- path/to/conflicting/file

（在这里你也可以用 git checkout --theirs 或者 --ours )

• 手动检查并且再重新应用从另一边对文件的更改:

git add path/to/conflicting/file

• 当这些更改都修复之后要构建整个项目，确保至少可以编译通过，如果测试可以很快运行起来，也要运行一下这些测试：

git commit

这个过程看起来有点太手工化了，但詹森发现对于他的工作流程来说会更少产生不合理的合并。

想看一步步手动解决冲突的基本视频，可以参看我们最近的 Git Power Routines 课程。