三路合并比两路合并强在能通过共同祖先（merge base）精准识别修改来源：仅当双方都改动同一处时才报冲突；两路合并因无基准，凡内容不同即误判为冲突。
三路合并到底比两路强在哪？
因为两路合并只看两个版本的差异，根本分不清“谁改了什么”，所以只要两行内容不同就报冲突——哪怕其中一方根本没动过那行。三路合并引入了共同祖先（merge base）作为参照点，能判断出：这一行是只有Ours改了、只有Theirs改了，还是双方都改了。只有最后一种情况才需要人工介入。
常见错误现象：git merge时一堆冲突，但打开文件发现很多只是“对方加了一行注释，我完全没碰这附近”——这就是典型的两路思维误判，而三路本该安静合并掉。
-
merge base不是随便选的，Git会自动找两个分支最近的共同提交；如果找不到唯一祖先（比如分支多次分叉再合并），Git会递归合并多个祖先生成虚拟基线 - 你无法手动指定
merge base，但可以用git merge-base branch1 branch2查看它实际用了哪个提交 - 某些老旧工具或自定义脚本若绕过Git原生逻辑做“补丁应用”，可能退化为两路行为，导致冲突率飙升
冲突标记里的和<code>>>>>>> feature-x怎么读？
这不是“左边是你的、右边是别人的”那么简单。代表当前分支（<code>Ours）相对于merge base的修改；>>>>>> feature-x代表待合并分支（Theirs）相对于同一merge base的修改。中间=======分隔的是二者分歧点。
使用场景：当你看到冲突块里两边代码逻辑其实等价（比如变量重命名、空格调整），说明merge base可能太老，或某次提交意外覆盖了另一方的改动——这时别急着删标记，先用git show <merge-base-hash>:path/to/file</merge-base-hash>确认基线内容。
- 冲突块可能跨多行，但Git只对“有变更的最小上下文单元”打标记，不是整段函数
- 如果同一文件出现多个冲突块，它们彼此独立，可分批处理，无需按顺序
-
git diff --ours和git diff --theirs能快速对比当前视图与各自分支最新状态，比反复翻commit更高效
git merge --no-ff和三路合并的关系
--no-ff不改变三路合并算法本身，但它强制生成merge commit，从而保留merge base的明确记录。没有它时，如果满足快进条件（HEAD是待合并分支的直接祖先），Git会跳过三路过程，直接移动指针——这时连merge base都不参与计算。
性能影响：快进合并瞬间完成，无计算开销；非快进合并必须执行完整三路比较，对大仓库或二进制文件较多的项目，git merge响应时间可能明显变长。
- 团队协作中，主分支（如
main）建议始终用--no-ff，否则历史里看不出哪次合入了feature分支 -
git merge --ff-only会拒绝非快进合并，适合CI流水线中要求线性历史的场景 -
merge commit的父节点永远是两个：一个是HEAD，一个是待合并分支头，第三个隐含的merge base只存在于算法内部，不写入commit对象
为什么cherry-pick也用三路合并？
因为cherry-pick不是简单打补丁。它把目标commit的父提交当作merge base，当前HEAD当作Ours，目标commit本身当作Theirs，然后跑一遍三路合并。所以即使原始commit在别的分支上能干净合入，在当前分支也可能冲突——merge base不同了。
容易踩的坑：有人用git format-patch + git apply模拟cherry-pick，但这退化为两路行为，丢失上下文，尤其当目标commit依赖其父提交里的某行删除时，git apply会直接失败，而cherry-pick能通过三路推导出该删除应被保留。
-
git cherry-pick -m 1 <merge-commit></merge-commit>指定取第一个父提交为base，用于挑拣合并提交中的某条路径 - 连续
cherry-pick多个commit时，每个都独立计算base，不会复用前一个的中间状态 - 如果
cherry-pick失败，git status显示的冲突文件和git merge完全一致，解决方式也相同
merge base的选择——它看不见、摸不着，却决定所有冲突是否发生。每次怀疑冲突不合理，第一反应不该是编辑文件，而是查git merge-base输出，确认Git到底拿哪个提交当“起点”。
