深入理解 Git 底层机制：指针（Refs）、提交（Commit）与分支的关系
1. Git 的核心数据结构
Git 用几个核心对象来保存版本历史：
- Blob（数据块）：存储文件内容，不包含文件名。
- Tree（树对象）：存储目录结构，包含文件名和指向 blob 或其他 tree 的指针。
- Commit（提交）：指向一个 tree，并包含元信息（作者、时间、父提交等）。
- Tag（标签）：给某个提交打上易记的标记，通常用于发布版本。
这些对象用 SHA-1 哈希值唯一标识，内容不可变。
2. 指针（Refs）：Git 版本历史的入口
Git 的历史是由大量 commit 组成的 DAG（有向无环图），这些 commit 是抽象的快照，指针（refs）就是用来“标记”这些提交的具体位置，方便我们快速定位和管理。
2.1 什么是 Refs？
Refs 是 Git 中用来指向某个 commit 的“指针”，本质上是存储在 .git/refs 目录下的文本文件，内容是 commit 的哈希值。
常见的 refs 类型包括：
- 分支（branch）：存在
.git/refs/heads/，例如.git/refs/heads/master文件里存的就是 master 分支当前指向的提交哈希。 - 标签（tag）：存在
.git/refs/tags/，比如v1.0标签指向某个稳定的提交。 - 远程分支（remote-tracking branch）：存在
.git/refs/remotes/，如origin/master指向远程仓库的 master 分支当前的提交。
2.2 HEAD：特殊的指针
HEAD 是一个特殊的引用，指示当前检出的分支或具体提交。通常它是一个符号引用，指向一个分支引用，比如：
ref: refs/heads/master
也可以是一个具体的 commit（detached HEAD 状态）。
3. 分支其实就是指针
Git 的分支其实非常轻量，就是一个指向提交的 refs。比如 master 分支其实就是 .git/refs/heads/master 文件，里面写着一个 commit 的 SHA-1。
当我们新提交一次，Git 只会移动这个指针到最新的 commit。分支并不复制任何文件或者提交，只是“指向”不同的提交节点。
4. 合并和分叉点（fork point）与公共祖先（merge-base）
Git 的提交形成 DAG 结构，每个 commit 都有 0 或多个父提交。
- 合并操作会产生一个有多个父节点的提交（merge commit）。
- 分叉点即两个分支的最近公共祖先提交（merge-base），Git 会从这个公共祖先开始比较两个分支的变化。
4.1 什么是 merge-base？
merge-base 指的是两个提交的“最近共同祖先”（lowest common ancestor）。它是 Git 用来计算两个分支差异、进行三方合并的关键。
4.2 merge-base 是如何找到的？
Git 把提交看作 DAG（有向无环图），节点是提交，边是父子关系。
找 merge-base 的过程就是：
- 从两个提交开始，往它们的父提交一路追溯。
- 找到第一个（最近的）在两个路径中都出现的提交，即公共祖先。
- 如果有多个公共祖先，Git 还会根据策略选出最佳的一个（或多个）。
简单说，就是在提交历史图中找到两个提交向上走时的“汇合点”。
好的，关于 merge-base 是如何通过遍历 commit DAG 找两个提交“最近的共同祖先”，我来详细讲讲具体原理和过程。
具体算法（高层伪代码）
def find_merge_base(commitA, commitB):# 维护两个队列，分别用来从 commitA 和 commitB 向上遍历queueA = [commitA]queueB = [commitB]# 用集合存储访问过的提交，防止重复访问visitedA = set()visitedB = set()while queueA or queueB:# 向上遍历 commitA 的历史if queueA:currentA = queueA.pop(0)if currentA in visitedB:return currentA # 找到共同祖先visitedA.add(currentA)queueA.extend(currentA.parents)# 向上遍历 commitB 的历史if queueB:currentB = queueB.pop(0)if currentB in visitedA:return currentB # 找到共同祖先visitedB.add(currentB)queueB.extend(currentB.parents)return None # 理论上不可能，git 是有根提交的
Git 底层的优化：
- Git 实际实现时会用更高效的数据结构和算法，如标记、优先级队列等。
- 它支持合并多个父节点（如合并提交有多个父），所以要处理多父节点的 DAG。
- Git 会遍历两个提交的祖先链，用“颜色标记法”标记访问路径，找到第一个交叉点。
4.3 为什么要找 merge-base？
合并时，Git 用 merge-base 作为对比点：
- 比较两个分支各自相对于
merge-base的改动。 - 自动合并两边改动，解决冲突。
比如：
A --- B --- C (master)/D --- E --- F (feature)
master 的最新提交是 C，feature 的最新提交是 F，他们的 merge-base 是 E。Git 会比较 E->C 和 E->F 的差异，合并后生成新的提交。
4.4 实际命令示例
git merge-base master feature
# 输出就是两个分支的最近公共祖先提交哈希