Git三方合并策略详解

一、什么是合并（Merge）

在 Git 中，合并的本质就是把两条独立开发线（也就是分支）的修改整合到一起。当你敲下 git merge 的时候，Git 需要仔细判断：这两个分支上的代码变更，到底该怎么拼成一个最终版本？

二、快进合并（Fast-Forward Merge）

在聊三方合并之前，先看看最简单的合并方式——快进合并。

场景

A --- B --- C (main)
              
               D --- E (feature)

假如 main 分支在你创建 feature 分支之后没有任何新提交，那合并就简单了——Git 只需要把 main 的指针直接挪到 feature 的最新提交上：

A --- B --- C --- D --- E (main, feature)

这就是快进合并，它不会产生新的合并提交。

特点

• 不会产生合并提交（merge commit）
• 历史记录是一条直线，非常干净
• 只有在目标分支没有新提交时才会触发

三、三方合并（Three-Way Merge）

什么时候触发

当两个分支都有各自的新提交时，Git 就没法简单快进了——必须执行三方合并。看这个例子：

A --- B --- C --- F --- G (main)
              
               D --- E (feature)

main 多了 F、G 两个提交，feature 多了 D、E 两个提交，Git 需要把两边的修改合在一起。

三方合并的“三方”是什么

三方合并涉及三个版本：

为什么需要共同祖先

假设某个文件的某一行：

• 在共同祖先中是 x = 10
• 在 main 中是 x = 10（没改）
• 在 feature 中是 x = 20（改了）

如果没有共同祖先做参照，Git 只看到 main 是 x = 10，feature 是 x = 20，完全没法判断该用哪个。

有了共同祖先，Git 的判断逻辑就清晰了：

• 共同祖先是 x = 10，main 也是 x = 10 → main 没改
• 共同祖先是 x = 10，feature 是 x = 20 → feature 改了
• 结论：采用 feature 的修改

四、共同祖先（Merge Base）

定义

共同祖先就是两个分支在提交历史中最近的共同节点。它代表着两个分支“分道扬镳”的那个时间点。

图示

         E --- F (feature-A)
        /
A --- B --- C --- D (main)
        
         G --- H (feature-B)

• feature-A 和 main 的共同祖先是 B
• feature-B 和 main 的共同祖先是 B
• feature-A 和 feature-B 的共同祖先也是 B

查找共同祖先

git merge-base  

这个命令会输出共同祖先的 commit SHA。

复杂场景：多次合并后的共同祖先

A --- B --- C --- D --- M1 --- E (main)
                     /
         F --- G --- H (feature)

如果 feature 曾经被合并到 main（M1），之后 feature 又继续开发，那再次合并时：

• 共同祖先不再是 B，而是 H（上次合并时 feature 的状态）

Git 会自动找到最近的共同祖先，确保只合并上次合并之后的新变更。

五、三方合并的决策规则

对于文件中的每一处差异，Git 按以下规则决定最终结果：

规则总结

1. 只有一方修改 → 自动采用修改方的版本
2. 双方做了相同修改 → 自动采用（无冲突）
3. 双方做了不同修改 → 产生冲突，需要人工解决
4. 双方都没改 → 保持原样

六、冲突（Conflict）

什么时候产生冲突

当同一处代码两个分支都做了不同的修改时，Git 无法自动决定用哪个版本，就会标记为冲突。

冲突标记

<<<<<<< HEAD
// 当前分支（ours）的代码
int count = getCount();
=======
// 目标分支（theirs）的代码
long count = getCount();
>>>>>>> feature

解决冲突

1. 手动编辑文件，选择保留哪个版本（或者把两者合并起来）
2. 删除冲突标记（<<<<<<<、=======、>>>>>>>）
3. git add 标记为已解决
4. git commit 完成合并

七、合并提交（Merge Commit）

三方合并完成后，Git 会创建一个特殊的合并提交——它有两个父提交：

A --- B --- C --- F --- G --- M (main)
                           /
               D --- E ----  (feature)

M 就是合并提交，它的两个父提交分别是 G（main 的最新）和 E（feature 的最新）。

查看合并提交的父提交

git log -1 --format="%P" 

输出两个 SHA，第一个是当前分支的父提交（ours），第二个是被合并分支的父提交（theirs）。

八、实际场景分析

场景：从旧分支合并到已更新的目标分支

时间线：
1月：dev 上有人把 Integer 改为 Long
3月：你从 master（还是 Integer）拉出 feature 分支
5月：你把 feature 合并到 dev

合并时的三方对比：

Git 判断：你没改这行，dev 改了 → 采用 dev 的 Long。

场景：你修改了同一行附近的代码

如果你在 feature 分支修改了 Integer count = ... 这行附近的代码（比如上下几行），Git 可能会：

• 把你修改的部分保留
• 把 dev 修改的部分也保留
• 如果两者修改了同一行 → 产生冲突

场景：你的分支不是从 dev 拉的

如果你从 master 拉分支，而 master 和 dev 的代码状态不同，合并到 dev 时共同祖先可能是很早之前的提交，导致大量差异需要合并，自动合并出错的风险会大幅增加。

九、合并策略选项

recursive（默认）

Git 默认使用 recursive 策略进行三方合并。当存在多个共同祖先时，它会递归地合并这些祖先来构造一个“虚拟祖先”。

ours

git merge -s ours feature

完全忽略对方的修改，保留当前分支的所有内容。用得少，但某些场景下挺管用。

theirs（通过选项实现）

git merge -X theirs feature

冲突时自动选择对方的版本。适合当你确定要完全接受外来分支的改动时使用。

十、最佳实践

1. 频繁同步：定期将目标分支（dev/main）合并到你的 feature 分支，减少最终合并时的差异
2. 从正确的分支拉取：如果要合并到 dev，就从 dev 拉分支，而不是从 master——否则共同祖先会非常远，隐患很大
3. 小步提交：每次提交的改动尽量小且聚焦，冲突范围自然就小了
4. 合并前先拉取最新：git fetch + git merge 确保本地是最新状态，避免“我以为是最新的”这种尴尬
5. 合并后立即验证：编译、运行测试，确保合并结果正确——别等到上线才发现问题

十一、总结

三方合并的核心思想其实就一句话：

通过共同祖先作为参照基准，判断每一处差异是“谁改的”，从而自动决定最终结果。只有当双方都改了同一处且改法不同时，才需要人工介入。

理解了这一点，你就不会再觉得合并后代码“自动变化”是 Git 出了毛病——恰恰相反，它正确地执行了三方合并的逻辑，只是你可能没注意到那个共同祖先的存在。