当 Git 提示 Automatic merge failed 时，说明合并过程中发现了无法自动处理的冲突，需要人工介入修改文件内容后才能完成合并。

命令速用版

如果你只是想快速查看当前状态或放弃合并，可以使用以下命令：

# 查看哪些文件冲突
git status

# 如果决定放弃本次合并，回到合并前的状态
git merge `--abort`

# 解决完冲突后，标记为已解决
git add <文件名>

# 完成合并提交
git commit

为什么会这样

Git 的合并机制是基于行内容的对比。当两个分支对同一个文件的同一行进行了不同的修改，或者一个分支修改了文件而另一个分支删除了该文件，Git 无法判断应该保留哪一方的更改，就会停止合并流程并抛出 Automatic merge failed。

这实际上是一种保护措施，防止你的代码被意外覆盖。此时 Git 会在冲突文件中插入特殊的标记符号，等待你手动决定保留哪部分代码。

分步处理

按照以下步骤操作，可以安全地解决冲突：

1. 定位冲突文件

在终端运行 git status，输出中会显示 unmerged paths 列表，这些就是需要处理的文件。

2. 编辑冲突内容

用编辑器打开冲突文件，搜索 <<<<<<<、======= 和 >>>>>>> 这三个标记。注意：解决冲突不仅仅是删除这些标记，必须理解上下代码逻辑，避免误删关键业务逻辑。

• <<<<<<< HEAD 下方是当前分支的内容
• >>>>>>> 分支名 下方是待合并分支的内容
• ======= 是分隔线

删除这些标记行，保留你需要的代码，确保逻辑通顺后保存文件。

3. 标记为已解决

文件修改保存后，Git 还不会自动知道冲突已解决。你需要运行：

git add <文件名>

如果有多个文件，可以逐个添加，或者确认无误后使用 git add .。

4. 完成提交

所有冲突文件都 add 之后，运行：

git commit

Git 会自动生成一条合并提交信息，你也可以根据需要修改。

冲突内容示例演示

为了让你更直观地理解，以下是一个典型的冲突文件内容示例（解决前 vs 解决后）：

解决前（包含冲突标记）：

function calculatePrice() {
    <<<<<<< HEAD
    return basePrice * 0.9; // 当前分支：打九折
    =======
    return basePrice * 0.8; // 合并分支：打八折
    >>>>>>> feature-discount
}

解决后（保留正确逻辑）：

function calculatePrice() {
    // 根据需求确认最终折扣，例如保留八折
    return basePrice * 0.8;
}

注意：不要简单地保留某一方，有时需要结合两边的逻辑进行修改。修改后务必本地运行测试验证。

怎么验证是否生效

处理完成后，通过以下方式确认合并是否成功：

1. 检查工作状态

运行 git status，如果输出显示 nothing to commit, working tree clean，说明没有遗留的冲突或未暂存的更改。

2. 查看提交历史

运行 git log `--oneline` `--graph`，可以看到当前分支已经包含了合并提交记录，且分支线已汇合。

3. 编译或运行测试

如果这是代码项目，建议本地运行一次构建或测试用例，确保解决冲突时没有误删关键逻辑导致语法错误或业务逻辑错误。

常见坑

1. 冲突标记未删干净

有时候手动编辑会漏掉某处的冲突标记，直接提交会导致代码中包含 <<<<<<< 这种字符，可能引发语法错误。提交前建议在编辑器里全局搜索一下这些标记。

2. 逻辑错误风险

删除标记后代码能运行不代表逻辑正确。例如两边修改了不同的变量名，合并后可能变量未定义。务必结合业务场景审查代码。

3. 二进制文件冲突

图片、压缩包等二进制文件无法通过文本对比解决。如果发生冲突，通常需要决定保留哪一个版本，然后直接 git add 覆盖。

4. 误用 git checkout

在解决冲突过程中，不要随意使用 git checkout <文件>，这可能会丢弃你刚才手动修改的内容。如果不小心操作错了，可以用 git reflog 尝试找回之前的状态。

5. 合并中途放弃

如果冲突太复杂想重新开始，记得用 git merge `--abort` 而不是直接强制切换分支，否则可能会留下残留的合并状态。