Git Internals
三方合并机制
理解 Git 如何基于 merge-base 做三方合并，有助于准确判断冲突来源、合并结果与冲突解决策略。
- 想建立稳定 Git 心智模型的学习者
- 经常遇到历史、引用、恢复问题的开发者
- 会看基础命令输出
- 知道提交、分支、HEAD 这些名词
- 只背底层术语却不连接到实际命令
- 把对象、引用、工作区混成一层理解
数据 / 性能事实
- merge basethe common ancestor is computed once; conflicts only arise where both sides changed the same region出处: git-merge-base(1) official manual
关键引语
Git performs a three-way merge by finding the common ancestor (merge base) of the two commits and using it as the baseline to combine the two sets of changes.
引用与延伸阅读
学完这篇你会掌握什么
- 理解 三方合并机制 的核心作用和适用场景
- 掌握 三方合并机制 的基本用法和常用参数
- 理解 Git 如何基于 merge-base 做三方合并，有助于准确判断冲突来源、合并结果与冲突解决策略。
- 理解 三方输入分别是什么 相关的概念
- 掌握 为什么会冲突 相关的操作
- 知道在什么场景下使用该命令，什么场景下避免使用
Git merge 的核心不是“把两边拼起来”，而是用三方输入计算结果：base、ours、theirs。
先想一个问题
你每天都在用 Git 命令，但偶尔会遇到一些 '奇怪' 的行为——比如明明没改文件却被提示有改动，或者 rebase 时突然多了预期之外的冲突。你想理解 Git 底层是怎么工作的。
三方输入分别是什么
base：两边分支共同祖先（merge-base）ours：当前分支 tiptheirs：被合并分支 tip
Git 对比的是 “base→ours” 与 “base→theirs” 的改动差异。
合并前
main
ABC
feature
BDE
合并后
main
ABCM
feature
BDEM
为什么会冲突
当两边都修改了同一位置且结果不可自动判定时，就会触发冲突。
一个常见误解
冲突不代表 Git 不知道文件结构，而是语义选择需要人工决策。
只看 ours/theirs 容易失去上下文。理解 base 的原始状态，通常能更快判断哪侧更合理。
接下来建议继续看什么
给你的练习
- 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
- 尝试该命令的不同参数选项，对比输出结果的差异
- 模拟一个需要使用该命令的实际场景，完整走一遍操作流程
延伸阅读
沿着同一主题继续深入：