合并冲突是 Git 协作里绕不开的环节。第一次看到 “Automatic merge failed” 时，很多人会以为仓库坏了，其实 Git 只是把需要决策的问题抛给了你。下面按我平时的排查顺序来写，先从报错信息里能读到的内容说起。
先看 Git 把冲突留在了哪里
执行git merge后，如果终端输出Automatic merge failed; fix conflicts and then commit the result.，就说明Git在合并时遇到了无法自动处理的冲突。此时运行git status，会看到处于Unmerged状态的文件列表，且文件内部插入了标记，分别展示当前分支和合并分支的改动。旁边通常还有CONFLICT (content)之类的提示，指出冲突文件。只有手动解决这些标记并提交，合并才算完成。
这行输出并不会让仓库处于危险状态。Git 在冲突时已经生成了合并状态，我们可以通过 git status 看到所有未合并的文件。要注意的是，冲突标记里的两段内容分别来自当前分支和合并进来的分支，顺序不要搞混。通常 <<<<<<< 到 ======= 是当前分支，======= 到 >>>>>>> 是合并进来的分支。先弄清这个次序，后面编辑才不会拿反。
容易误判的地方
一个常见的误判是，认为只要把冲突标记删掉，问题就解决了。实际上标记只是提示边界，真正要决定的是保留哪一方的改动，或者整合成新的写法。另一个误判是只看冲突文件本身，没有留意相同逻辑在其他位置是否也受到影响。比如两个分支同时新增了一个函数，但函数名不同，Git 不会产生冲突，合并后可能同时存在两份逻辑，留下隐患。
还有一种情况是同事改了文件名，你又改了原文件内容，Git 会把冲突标在旧文件名上，这时候需要意识到文件已经被重命名，手动处理后还要考虑是否保留原文件名。处理这类问题，建议先和提交相关改动的人确认意图。
解决冲突前的检查顺序
在动手编辑之前，先跑一遍检查命令，往往能省掉不少返工。下面这段是我常用的做法。
在提交前，可以运行git diff --check，它能检查出未解决的冲突标记和多余的空白字符。想更细致地了解改动，则执行git diff，重点观察冲突区域的修改是否符合预期。如果冲突文件较多，建议先浏览所有文件，再用git log --merge查看两个分支最近提交的差异，帮助判断冲突来源。做完这些检查，再逐个git add，能降低解决失误的概率。
git diff --check 的输出如果为空，说明至少没有残留的冲突标记，但它不会检查逻辑正确性。所以接着看 git diff 时，要特别留意代码结构是否完整，比如括号是否配对、变量名是否一致。对于配置文件，还要盯着缩进和逗号，Git 不会帮你判断这些。
处理冲突的具体步骤
- 先运行
git status列出所有冲突文件。 - 逐个打开文件，搜索
<<<<<<<标记。 - 针对每个冲突区域，根据上下文决定保留哪一段，或者手动编辑成新内容。
- 删除冲突标记后，运行
git add标记为已解决。 - 全部解决后，运行
git diff --cached检查暂存内容。 - 执行
git commit提交合并结果，Git 已经准备好默认的合并提交信息。
这个顺序里最关键的是第 4 步。Git 只认你是否 git add 了冲突文件，加完就算解决，哪怕你只是把标记删了。所以 add 之前一定要保证文件内容是真的定稿了。
撤销和风险边界
如果冲突范围大或思路混乱，先不要手动编辑，执行git merge --abort可以完全放弃本次合并，回到合并前状态。对于已经改了一半但发现改错的场景，可以先用备份工具备份冲突文件，再用git checkout --ours或--theirs恢复某一方版本。但需要注意，--ours和--theirs的语义与当前所在分支有关，操作前务必用git branch确认处于哪个分支，避免拿到反方向的内容。
git merge --abort 最保险，但它会丢弃合并过程中所有修改，包括你手动编辑过的文件内容。所以如果你在冲突处理中改过一些代码但还没提交，想留着这些改动，就别用它。至于 --ours 和 --theirs，常用于快速把一个文件恢复成某一方的完整版本，但是它们只针对冲突路径有效，而且在你处于 rebase 状态时，两个选项的含义会相反。因此，操作前用 git branch 看清当前位置，再决定用哪一侧。
合并完成之后，别急着继续干活，先运行 git status 确认工作区干净，再用 git log -1 看看新的合并提交是否确实由你生成。如果发现这次合并结果不对，只要还没 push 到远程，可以通过 git reset --hard HEAD~1 回到合并前，但前提是你没有其他未提交的改动。每次合并冲突都是一次代码 review 的机会，处理完再回头看一眼 diff，能沉淀出对代码库更深的理解。