为什么会出现 Git 合并冲突
当你在两个分支上修改了同一个文件的同一部分，Git 无法自动判断哪份修改应该保留，就会在合并时产生冲突。Git 合并冲突的本质是：两个提交都改变了相同位置的内容，且 Git 的合并算法无法自动合并这些更改。了解这一点，你才能对症下药。
如何检测合并冲突
当你执行 git merge 或 git pull 时，如果存在冲突，Git 会输出类似以下信息：
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
此时，使用 git status 可以查看哪些文件处于未合并状态。冲突文件会同时出现在“Changes to be committed”和“Unmerged paths”部分。Git 还会在冲突文件中插入冲突标记，帮助你定位冲突位置。
冲突标记长什么样
打开冲突文件，你会看到类似下面的内容：
<<<<<<< HEAD
这是当前分支的修改
=======
这是被合并分支的修改
>>>>>>> feature-branch
其中：
<<<<<<< HEAD到=======之间的内容来自当前分支（HEAD）。=======到>>>>>>> feature-branch之间的内容来自被合并的分支。
手动解决冲突的详细步骤
解决冲突的核心是：编辑文件，删除冲突标记，保留你想要的最终内容。以下是具体步骤：
- 打开冲突文件：使用编辑器打开包含冲突标记的文件。
- 定位冲突区域：搜索
<<<<<<<标记，逐个检查每个冲突。 - 决定保留内容：根据需求，保留当前分支的修改、被合并分支的修改，或者两者结合。
- 删除冲突标记：删除
<<<<<<<、=======、>>>>>>>这些行。 - 保存文件：保存修改后的文件。
- 标记为已解决：使用
git add <文件名>将文件标记为已解决。 - 完成合并：所有冲突解决后，执行
git commit完成合并提交。
示例：解决一个具体的冲突
假设你在 main 分支上修改了 index.html 的标题为“首页”，同时在 feature 分支上修改了同一行为“欢迎”。合并后，文件内容如下：
<title><<<<<<< HEAD
首页
=======
欢迎
>>>>>>> feature
</title>
如果你希望保留“欢迎”，则编辑文件为：
<title>欢迎</title>
然后执行：
git add index.html
git commit -m "Merge branch 'feature'"
这样就完成了冲突解决。
使用合并工具解决冲突
手动编辑虽然直观，但面对复杂冲突时效率较低。Git 支持使用外部合并工具，例如 kdiff3、meld 或 VS Code 内置的合并编辑器。配置方法：
git config --global merge.tool meld
git mergetool
执行 git mergetool 后，Git 会打开配置的工具，让你可视化地选择左右两侧的修改。工具会生成三个文件：.orig 原始文件、LOCAL（当前分支）、REMOTE（被合并分支），你可以在工具中直接编辑最终版本。保存后，关闭工具，Git 会询问是否已解决，确认后自动标记为已解决。
如何预防合并冲突
虽然冲突无法完全避免，但以下措施可以显著减少冲突频率：
- 保持分支短小：频繁合并，减少分支之间的差异积累。
- 及时更新主线：定期将
main分支的更新合并到你的功能分支，避免大范围分叉。 - 避免同时修改相同文件：团队成员之间沟通，尽量分工明确。
- 使用
git pull --rebase：在推送前将远程更新变基到本地，使提交历史线性化，减少合并冲突。
常见误区与陷阱
解决冲突时，新手常犯以下错误：
- 忽略冲突标记：直接删除标记而不修改内容，可能导致代码逻辑错误。
- 只保留一个版本：有时正确的做法是结合两个版本的修改，而不是二选一。
- 过早提交：未运行测试就提交，可能引入隐藏问题。
- 误用
git checkout --ours：这会直接丢弃对方修改，除非你明确知道后果，否则慎用。
参考资料
关于版本控制和代码管理的更多信息，可参考以下资源：
- Python 官方文档：了解编程语言基础，有助于理解代码冲突。
- MDN Web 开发文档：涵盖 Web 技术，包括 HTML、CSS、JavaScript，常用于冲突示例。
另外，你还可以参考站内相关文章：Git 分支管理最佳实践 和 Git 常见错误与解决方法。
延伸阅读