虚拟公共祖先是在两分支无直接共同祖先时，git递归合并多个共同祖先生成的合成快照；它仅用于本次三路合并计算，不对应真实commit，启用条件是git merge发现多个merge base且未禁用recursive策略。
什么是虚拟公共祖先（virtual merge base）
当两个分支没有直接的共同祖先提交时，Git 会尝试构造一个“虚拟”的合并基础点，而不是报错或拒绝合并。这种虚拟公共祖先不是真实存在的 commit，而是 Git 通过递归合并多个共同祖先后合成出来的快照。它只在 recursive 策略下启用，resolve 策略遇到多祖先就直接失败。
为什么需要虚拟公共祖先
真实项目中常出现“多叉祖先”场景：比如分支 A 和 B 分别从不同时间点的 master 切出，又各自被 merge 过其他特性分支，导致它们有多个共同祖先。此时 git merge-base A B 可能输出多个哈希值，而标准三路合并只能接受一个 base。
- 不引入虚拟祖先 →
git merge报错 “refusing to merge unrelated histories” 或 fallback 到ort策略（Git 2.34+ 默认） - 引入虚拟祖先 → Git 自动对所有共同祖先做两两递归合并，直到收敛出唯一 base 快照
- 该过程不可逆、无对应 commit 对象，仅用于本次合并计算差异
如何触发虚拟公共祖先生成
典型触发条件是存在多个 merge base，且你没显式禁用递归策略：
- 执行
git merge branch-b时，Git 内部调用get_merge_bases_many()发现 >1 个祖先 - 自动切换到
recursive策略（即使你没写-s recursive） - 对这些祖先两两做合并，生成中间虚拟快照，再以此为 base 计算 HEAD 与
branch-b的 diff - 若中间合并本身又产生冲突，Git 会在合并过程中提示 “Auto-merging … conflict” 并停在 index 中
你可以用 git merge-base --all A B 查看所有候选祖先，如果输出不止一行，就说明虚拟祖先很可能被激活了。
虚拟祖先带来的实际影响
它让合并“能继续”，但也带来几个容易被忽略的副作用：
- 合并结果可能和手动选某个祖先做三路合并不一致 —— 因为虚拟 base 是合成的，不是真实历史节点
-
git log --merge不会显示虚拟祖先，但它影响了冲突标记中的 - 某些 diff 工具（如 VS Code 内置）可能无法正确渲染虚拟 base 的变更上下文
- CI 环境中若依赖
git merge-base输出做判断，需注意它返回的是真实祖先，不是虚拟的那个
真正复杂的地方在于：你没法 git checkout 到那个虚拟祖先，也没法用 git show 查看它 —— 它只活在内存里，合并完就丢弃。处理这类合并时，别只盯着冲突行，得回溯多个祖先的修改路径才能判断哪边逻辑更合理。
