git merge底层原理解析

日常工作中常常会有这样的合并需求：现在我在A分支上，我想把B分支的内容合并上来。

合并步骤如下所示

1. 确保在 A 分支上

运行以下命令，确认当前处于 A 分支：

git branch

当前分支前会有一个 * 标记。如果不在 A 分支上，可以通过以下命令切换：

git checkout A

2. 合并 B 分支到 A 分支

执行以下命令：

git merge B

3. 解决冲突（如果有）

如果在合并过程中有冲突，Git 会提示冲突文件。解决冲突步骤如下：

1. 打开冲突文件，手动选择保留内容。
2. 标记冲突已解决：
   git add <冲突文件>
3. 继续完成合并：
   git commit

4. 检查合并结果

查看合并是否成功：

git log --oneline --graph

5. 推送到远程仓库（可选）

如果需要将 A 分支的最新内容推送到远程：

git push origin A

这样，B 分支的内容就被合并到 A 分支了。

现在我们看一下底层的原理是怎样的？

1. 基本原理

git merge 通过合并提交历史来生成一个新的提交（通常称为“合并提交”），将两个分支的内容整合到一起。其核心任务是找到合适的共同祖先，并基于此计算变更。

---

2. 核心算法

Git 的合并主要基于三方合并算法（Three-way merge algorithm）：

• 三方合并：涉及三个点：
  1. 共同祖先（common ancestor）：两个分支分叉之前的最后一个共同提交。
  2. 当前分支（HEAD）：正在执行合并操作的分支。
  3. 目标分支（要合并的分支）：被合并进来的分支。

具体步骤：

1. 找到共同祖先（Common Ancestor）： Git 使用 Lowest Common Ancestor (LCA) 算法，通过分支的提交图（DAG 结构）找到两个分支的共同祖先节点。

2. 生成差异（Diff）：

   • HEAD 和祖先的差异：表示当前分支对祖先提交的改动。
   • 目标分支和祖先的差异：表示目标分支对祖先提交的改动。

3. 合并变更：

   • Git 将两个差异整合到一起。如果没有冲突，则直接合并。
   • 如果有冲突（即两个分支对同一文件的同一区域进行了不同的修改），Git 会标记冲突区域，提示用户进行手动解决。

4. 生成合并提交：

   • 在合并完成后，Git 会创建一个新的提交，包含两个父提交（HEAD 和目标分支的最新提交），形成提交图上的分叉和合并。

---

3. Fast-forward 合并

如果当前分支是目标分支的祖先分支，Git 会执行快进合并（Fast-forward Merge）。此时无需创建新的合并提交，只需将当前分支指向目标分支的最新提交。

条件：

• 当前分支与目标分支之间没有分叉。
• 使用 git merge --no-ff 可以强制创建合并提交，即使可以快进。

---

4. Recursive 合并

当分支有多个共同祖先时，Git 使用递归合并策略（Recursive Merge Strategy）：

• 合并多个共同祖先，生成一个虚拟的共同祖先（称为伪祖先）。
• 基于该伪祖先执行三方合并。

---

5. 冲突检测

合并过程中，Git 会检测文件内容冲突（Content Conflict）以及文件结构冲突（例如文件被一个分支修改，另一个分支删除）。冲突的解决方式包括：

• 手动解决：用户编辑冲突的文件。
• 使用工具解决：使用 git mergetool 配合合并工具。
• 丢弃更改：选择保留某一分支的修改。

---

6. 合并策略

Git 提供多种合并策略，通过 git merge 的 --strategy 参数指定：

• recursive（默认）：递归合并，适用于多数场景。
• ours：保留当前分支的所有改动，忽略目标分支的变更。
• octopus：用于合并多个分支，常用于非冲突的简单合并。
• resolve：类似于 recursive，但仅适用于两个分支的合并。
• subtree：适用于子树合并，用于复杂的项目分支管理。

---

7. 合并的底层数据结构

Git 基于 DAG（有向无环图） 的提交历史结构进行合并操作：

• 每个提交都是 DAG 图上的一个节点。
• 分支是 DAG 中的一条路径。
• 合并提交有两个或更多的父节点，表示分叉的分支被合并。

---

8. 性能优化

Git 在合并时使用以下技术优化性能：

• 哈希表缓存：加速对象和树的查找。
• 增量差异计算：只计算必要的差异。
• 索引（Index）：暂存区加速冲突处理。

下一篇单独讲解三方合并算法源码。