三路合并比两路多的“一路”是共同祖先（base），即base→ours和base→theirs两条变更路径，而非多一个分支；只有当两者均修改同一行且内容不同时才报冲突，否则自动采纳单方修改。
三路合并到底比两路多哪“一路”？
不是多一个分支，而是多一个共同祖先（base）——这才是三路合并能减少误报冲突的根本原因。两路合并只看 ours 和 theirs 两份文件，行不同就标冲突；三路合并会先找出它们共同的上一个版本 base，再分别对比：base → ours 改了什么、base → theirs 改了什么。
只有当两者都改了同一行（或重叠区域），且修改内容不同时，才真正标记为冲突。比如：
-
base中是Console.WriteLine("Hello World!"); -
ours改成Console.WriteLine("Hello Walterlv!"); -
theirs改成Console.WriteLine("Hello Master!");
这时 Git 才会生成冲突块；但如果 theirs 没动这行，Git 就直接采纳 ours 的修改，不报冲突。
为什么有时候 merge 会卡住，提示 “Auto-merging xxx” 但没报冲突？
这是 Git 正在执行三路合并的静默阶段：它已找到 base，并确认 ours 和 theirs 的修改区域互不重叠，于是自动写入合并结果，只在控制台输出提示。这不是卡死，而是成功合并的正常信号。
容易踩的坑：
- 误以为没反应就是失败，反复 Ctrl+C 中断，导致工作区残留未提交状态
- 忽略
git status输出中 “both modified” 类提示，其实那才是真冲突前兆 - 在 VSCode 中看到文件变蓝（已暂存）但没注意右下角 Git 插件弹出的 “Merge in progress” 提示
递归三路合并在什么情况下被触发？
当两个分支的最近公共祖先不唯一时（即存在多个 merge base），Git 无法直接选一个 base 做三路比较，就会启动递归三路合并：先尝试把多个候选 base 合并成一个虚拟提交（virtual base），再用这个虚拟提交作为新 base 继续三路合并。
典型场景：
- 你从
master分出feature/A，同事也从同一master分出feature/B -
feature/B先合入master，你却没git pull同步 - 此时
feature/A与最新master的共同祖先可能有多个（比如commit B和commit C都算）
这种情况下，Git 会先尝试合并 B 和 C 得到虚拟 base，再继续。但若 B 和 C 本身就有冲突，递归过程也会失败并抛出错误：error: commit XXX is a merge but no -m option was specified。
VSCode 里点 “Accept Current Change” 为什么有时反而引入 bug？
VSCode 的合并编辑器默认只展示 ours 和 theirs 两栏，隐藏了 base —— 这让你看不到“谁删了什么”“谁加了什么”，只看到最终差异。比如：
-
base有函数init()调用 -
ours把它删了（重构移除） -
theirs在同位置加了新调用setup()
如果你只看两栏，可能觉得 setup() 是新增逻辑，点了 “Accept Current Change”，结果就把 init() 的删除也丢掉了——而这个删除本该保留。
真正安全的做法是：
- 打开命令面板（
Ctrl+Shift+P），运行Git: Show Merge Conflicts查看完整三路视图（含base） - 或手动执行
git show :1:file.js（:1是base）、git show :2:file.js（:2是ours）、git show :3:file.js（:3是theirs）逐个比对
三路合并的精妙之处不在自动解决多少冲突，而在帮你看清“改了什么、为什么改”。一旦跳过 base 这一层，所有决策就只剩盲猜。
