merge-file 是 Git 底层三路合并工具，仅对三个纯文本文件（base/ours/theirs）执行合并计算，不操作分支、提交或工作区；而 git merge 是高层命令，用于合并分支历史，内部可能调用类似逻辑但完整管理索引、HEAD 和冲突处理。
merge-file 是什么，和 git merge 有什么关系
merge-file 是 Git 提供的一个底层工具命令，不是日常开发中直接调用的「合并分支」命令，它只负责对**三个纯文本文件**（base、ours、theirs）做一次三路合并计算，并输出结果到标准输出或指定文件。它不涉及分支、提交、索引或工作区状态——换句话说，git merge 在内部遇到冲突时，可能调用类似逻辑，但你手动运行 merge-file 并不会触发任何分支操作，也不会修改 HEAD 或暂存区。
常见误解是把它当作 git merge 的替代品。实际上，它更像一个「冲突模拟器」或「调试辅助工具」：当你想绕过 Git 的分支上下文，单独验证某段文本在 base/ours/theirs 三版本下的合并行为时才用得上。
什么时候该用 merge-file，而不是 git merge
绝大多数情况下不该用 merge-file。只有以下几种真实场景值得考虑：
- 调试自定义合并驱动（custom merge driver）的行为，比如你为
.json文件写了脚本，想脱离 Git 环境单独测试它的三路输入输出 - 自动化流水线中需要预判某个文件是否会在下一步
git merge中冲突（先用git show提取 base/ours/theirs 三个 blob，再喂给merge-file） - 教学或逆向分析：想直观看到三路合并算法对某段代码的实际决策（例如
如果你只是想把 feature 分支合进 main，直接运行 git merge feature 即可。硬套 merge-file 反而要自己找 base commit、提取文件内容、处理换行符差异，徒增出错概率。
merge-file 的参数顺序和常见踩坑点
merge-file 要求严格按顺序传入三个文件：merge-file <ours> <base> <theirs>。注意：它和 git merge 的语义相反——ours 是「当前分支内容」，theirs 是「待合并分支内容」，但 base 必须放在第二位，不能颠倒。
容易出错的地方：
- 路径写错导致读空文件，输出全是冲突标记（
<<<<< ours），但你以为是算法问题，其实是 base 没加载进来 - 文件编码或换行符不一致（比如 base 是 LF，ours 是 CRLF），
merge-file会当作不同内容处理，直接标冲突，而非 Git 那样受core.autocrlf影响 - 没加
-q参数时，它会在 stdout 输出成功提示（如Merged "file.txt"），干扰你解析实际合并结果 - 它默认不写入文件，必须用重定向（
> merged.txt）或-A选项，否则只打印到终端
一个可验证的 minimal 示例
假设你有三个临时文件：
echo "line1\nline2" > base.txt echo "line1\nline2-modified" > ours.txt echo "line1\nline2-also-modified" > theirs.txt
运行：
merge-file ours.txt base.txt theirs.txt
输出会是：
<<<<< ours line1 line2-modified ======= line1 line2-also-modified >>>>> theirs
这说明三路合并无法自动裁决——和你在 git merge 中看到的冲突格式完全一致，只是少了分支名（HEAD / feature/auth）。这也印证了：Git 的冲突标记本质就是 merge-file 这类底层逻辑的外露形式。
真正麻烦的从来不是工具本身，而是搞不清 base 从哪来、ours 和 theirs 哪个对应哪个分支、以及为什么看似相同的修改会被判为冲突——这些都得回到 commit 图谱里查公共祖先，而不是靠 merge-file 猜。
