三路合并比较的是共同祖先（base）、当前分支HEAD（ours）和待合并分支HEAD（theirs）三个版本；Git以此为基础判断变更意图，仅当双方均修改同一行且内容不同时才标记冲突。
三路合并到底在比哪三个版本？
Git 不是简单对比你当前分支和目标分支的最新提交，而是找三个关键提交点：共同祖先（base）、当前分支 HEAD（ours）、待合并分支 HEAD（theirs）。这三者构成“三路”，缺一不可。
常见错误是以为 git merge feature 就只是把 feature 的改动“搬”过来——实际 Git 会回溯到两个分支分叉前的最近公共提交作为基准，再分别计算 ours 和 theirs 相对于该基准的变更。只有当两者都改了同一行，且修改内容不同时，才标记冲突。
- 如果
ours没动某行，theirs改了 → 自动采用theirs的修改 - 如果
theirs没动某行，ours改了 → 保留ours的修改 - 如果双方都改了同一行，且内容不同 → 冲突标记：
<<<<<<HEAD/=======/>>>>>>feature
为什么有时没改文件也报冲突？
典型场景：你在 main 上没动某个配置文件，别人在 feature 分支删掉了它。合并时 Git 发现 base 中有该文件，ours 仍有（未删），theirs 已删 → 这属于“一方删除、一方保留”的分歧，Git 无法自动判断意图，直接报冲突。
这不是 bug，是算法对语义的保守处理。类似情况还包括：重命名 + 修改、空格/换行差异被 Git 视为实质性变更（取决于 core.whitespace 设置）。
- 用
git diff base..ours和git diff base..theirs分别看两边改了什么，比直接看冲突块更直观 - 检查是否启用了
merge.renormalize，它会影响空格/行尾处理逻辑 - 删除文件的冲突常被忽略，但它是三路合并中合法且高频的冲突类型
递归三路合并解决什么问题？
当两个分支的共同祖先不止一个（比如多次合并产生多个 merge-base），Git 会先两两合并这些祖先，生成一个虚拟的“合成祖先”，再用这个合成祖先做最终三路合并——这就是递归三路合并（recursive 策略，默认启用）。
它不是锦上添花，而是必要机制。例如：分支 A 合并过 B，B 又合并过 C；此时 A 和 C 的共同祖先可能有多个，仅选一个会导致部分变更丢失或误判。
- 可通过
git merge-base --all main feature查看所有候选祖先 -
git merge -s resolve强制禁用递归，但仅适用于双祖先场景，日常勿用 - 递归过程出错时，错误信息通常是
fatal: refusing to merge unrelated histories或merge returned 1
冲突标记里 HEAD 和分支名谁对应 ours/theirs？
在冲突块中，<<<<<<HEAD 永远代表当前所在分支（ours），>>>>>>feature（或实际分支名）代表被合并进来的分支（theirs）。这个顺序与 git merge 命令的执行上下文强绑定，跟“谁主动谁被动”无关。
容易踩的坑是：切到 feature 分支后执行 git merge main，此时 HEAD 在 feature，theirs 是 main —— 但多数人潜意识仍认为 main 是“主干”，误把 HEAD 块当成“对方修改”。
- 永远以命令执行时的当前分支为
ours，目标分支为theirs -
git status输出里的 “merging” 提示能帮你确认当前上下文 - 编辑冲突时，删掉标记行（
<<<<<<、=======、>>>>>>）本身不算解决，必须留下唯一有效内容
