出现这个提示时，我一般不会马上打开文件去改，而是先让 Git 告诉我当前处于什么阶段。这一步看起来慢，但能省掉后面很多来回操作。当Git报出Automatic merge failed时，第一件事不是急于去改文件，而是运行git status查看当前合并状态。典型输出中会有类似“Unmerged paths”和“both modified”的提示，这表示冲突发生在工作区的未合并区域。这些文件通常已经被Git打了标记，但尚未写入暂存区。如果输出显示“All conflicts fixed but you are still merging”，说明冲突已解决但尚未提交。还有一种情况是“error: you have not concluded your merge”，这往往意味着之前某次合并没有正确结束，需要先提交或中止。明确这些状态，才能决定下一步是继续解决冲突还是回退合并。

我在实际操作中会特别留意“both modified”这类字眼，因为如果只是单侧修改，Git一般能自动合并；出现双侧修改，才需要手动取舍。如果看到的是 All conflicts fixed 但还没提交，那就不需要再改文件，直接提交即可。而如果是 you have not concluded your merge，说明仓库里还挂着一次未收尾的合并，这时候要先处理旧状态，再谈新合并。

冲突文件怎么改才算解决

确认状态之后，真正的处理动作集中在冲突文件上。解决冲突的核心步骤是手动编辑每个冲突文件。Git会在冲突位置用‘>’标记两侧的代码，你需要保留自己想要的部分，并删除这些标记。编辑完成后，对每个文件执行git add，将文件标记为已解决。注意此时不要直接执行git commit，因为Git会生成提交信息，但最好先运行git diff --cached确认暂存内容无误。完成所有文件后，使用git commit -m 'merge'提交最后一次合并结果。如果中途想放弃，可以执行git merge --abort，但这一步会撤销本次合并的所有更改，包括你已经解决的部分，所以务必谨慎。

这里的冲突分隔符实际长这样：

<<<<<<< HEAD
当前分支的内容
=======
合并进来的内容
>>>>>>> feature-branch

编辑时要把这些标记连同不需要的内容一起删掉。每处理完一个文件就 git add 一个，不要攒到最后一起 add，否则很容易漏文件。git diff --cached 可以让你在提交前看到即将进入提交的差异，确认没有误删。之前有人问过我“为什么我都按提示改了，提交还是提示冲突？”通常就是因为没有 git add，Git 仍认为文件处于未合并状态。

文件多时怎么定位冲突范围

如果一次合并涉及十几个文件，逐个打开看会很累，先把清单列出来更实际。当冲突文件很多时，逐个打开太慢。建议先执行git diff --name-only --diff-filter=U列出所有冲突文件的清单，这个命令只输出未合并路径，方便集中处理。如果要查看每个文件的具体冲突内容，用git diff --diff-filter=U，它会显示两侧代码的变化。另外，git log --merge有助于了解冲突涉及哪些提交，可以辅助判断取舍依据。如果需要对比某个文件在当前分支和目标分支的版本，使用git show HEAD:file和git show MERGE_HEAD:file。这些命令都能在合并失败后的混乱状态下提供所需的上下文信息，避免盲改。

这几条命令可以配合用，比如先用 name-only 拿到清单，再挑出重点文件查看内容差异。git show HEAD:file 和 git show MERGE_HEAD:file 适合在犹豫“到底该保留哪边”的时候，直接看两个完整版本，而不是只盯着冲突标记附近的小片段。git log --merge 展示的是两个分支在共同祖先之后的提交，能帮你理解为什么这里会分叉。

看似冲突但实际不是代码问题的几种情况

有一部分 Automatic merge failed 并不是真的代码冲突，盲目去改文件反而浪费时间。我遇到过文件权限变化触发合并失败的情况，Git 只记录可执行位，两个分支对同一个文件设置了不同权限，git status 会显示 both modified，但打开文件内容完全一样。还有二进制文件冲突，Git 无法自动合并，只能提示失败。如果合并同时涉及大量删除和新增文件，Git 在计算差异时可能因为内存不足失败，提示信息会变成 Failed 而不是 Conflict。这些情况都需要先看文件类型和权限，再决定处理策略。

另外，工作区有未提交的本地更改时，也会出现 Automatic merge failed 但没有冲突标记。这种场景的处理顺序是：先运行 git stash 把本地修改暂存，再重新合并，合并成功后再 git stash pop 恢复。如果文件被外部工具锁定，比如 IDE 正在占用文件，Git 提示 Automatic merge failed 但实际没有冲突标记，可以先关闭可能锁文件的程序再试，必要时执行 git gc 或重启系统。这些步骤能覆盖大多数非代码冲突的场景。

中止合并前，先把当前进度留好

看到一堆冲突时，很多人会想直接 git merge --abort 回到原点。这个操作本身不复杂，但风险在于它会丢弃当前合并产生的所有变更，回到合并开始前的工作状态。如果你的工作区在合并前有未提交的本地更改，这些更改也可能被一并清除。所以我在执行 abort 前会先问自己几个问题：这些更改是否值得保留？有没有备份？如果已经手动解决了一部分冲突，又不想完全丢，可以用 git diff 或 git format-patch 把当前合并状态导出为补丁，再在 abort 后重新应用。更稳妥的办法是先 git stash 暂存未提交的修改，再处理合并。总之，中止不是不能选，而是要确认没有丢掉有价值的东西。

有时你只是对某个文件的取舍不确定，也不必立刻 abort。可以把冲突区域改成你想要的样子，先提交，再在下一轮修改中调整。提交历史里多一条合并记录，总比丢掉几个小时的工作容易接受。