详细介绍Git分支合并冲突时的三方合并算法（原理深度游）

Git在执行三方合并时，为什么必须定位到共同祖先？缺少这个基准点，就无法区分某行变化是“你加的”还是“对方删的”。简单场景下，如果两份文件都少了同一行——可能是你删了、对方也删了，也可能是你没动、对方删了——只有通过三方比对才能准确判断。

三方合并为什么必须找共同祖先

Git不是简单对比两个分支的最新文件，而是要通过get_merge_base()在提交DAG中递归搜索，找到HEAD和MERGE_HEAD的最近共同祖先。如果存在多个候选祖先（比如Octopus合并），还会进一步筛选出最低公共祖先。一旦找错了base，后续所有差异计算都会失准，轻则误报冲突，重则静默丢代码。

这个基准点的作用在于：它能清晰区分“谁修改了哪行”。假设两份文件都删除了同一行——如果你删了、对方也删了，合并时应该保留删除结果；但如果你没动、对方删了，同样需要采纳删除。两种情形结果相同，但意图截然不同，只有三方比对才能还原真实语义。

冲突标记

当diff_tree_merge()发现同一文件在ancestor→HEAD和ancestor→MERGE_HEAD两组差异中，都修改了完全重叠的行范围时，Git就会拒绝自动合并，并在工作区文件里写入冲突标记。

这些标记不是Git“凭空”插进去的，而是由merge-recursive.c中的tra verse_trees_recursive()在写入工作区时主动注入的：

• <<<<<< HEAD到=======之间是HEAD分支的变更内容（也就是本地暂存区Stage 2的快照）
• =======到>>>>>> feature-x之间是MERGE_HEAD分支的变更内容（对应远端Stage 3）
• 中间不会出现Stage 1（共同祖先版本）的原始内容——它只存在于Index中，供git diff --ours或git diff --theirs调用

Index里三个stage是怎么共存的

冲突发生后，执行git ls-files -u会列出同一个文件名对应三行输出，每行带不同stage编号和blob hash。这说明Git的Index（暂存区）此时不再是一维表，而是一个支持多版本映射的结构。

Stage 1/2/3并非临时状态，而是Git合并引擎的正式接口设计：

• Stage 1存储共同祖先版本的blob hash，仅作比对依据，不可编辑
• Stage 2是当前分支（HEAD）修改后的版本，对应本地工作区“看起来应该保留”的内容
• Stage 3是待合并分支（MERGE_HEAD）的版本，代表对方的意图
• 执行git add 后，这三个stage记录会被清空，Index回归Stage 0单一状态

很多人以为手动删掉冲突标记就完事了。但只要Stage 1/2/3还在Index里，git status就永远显示Unmerged paths，git commit也会被拒绝。真正解决问题的是git add，而不是删除标记本身。

为什么git merge --no-ff能帮你避开部分隐性冲突

--no-ff强制创建merge commit，表面看只是多了一个提交节点，但实际影响深远：它把每次合并的三方关系（base + ours + theirs）固化为一次性提交对象，后续git blame或git log --merge都能回溯到那次合并的完整上下文。

更关键的是，它避免了fast-forward合并带来的“历史扁平化”问题。如果连续几次FF合并，共同祖先可能退回到数周前的某个旧提交，导致后续合并时base过老，把本可自动解决的修改判为冲突。而带merge commit的历史，让Git总能找到更近、更准确的base。

真正容易被忽略的点是：--no-ff并不改变三方算法本身，但它让base的选取更稳定、更可预期。这不是“防冲突”，而是“让冲突更可信”——它让冲突仅仅出现在真正有分歧的地方，而不是因为历史扁平化导致的误判。