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 需要把两边的修改合在一起。

三方合并的"三方"是什么

三方合并涉及三个版本：

角色	说明	示例
共同祖先（Merge Base）	两个分支最近的共同提交	提交 C
当前分支（Ours）	你当前所在的分支的最新状态	提交 G
目标分支（Theirs）	你要合并进来的分支的最新状态	提交 E

为什么需要共同祖先

假设某个文件的某一行：

在共同祖先中是 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

查找共同祖先

bash 复制代码

git merge-base <branch1> <branch2>

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

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

复制代码

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

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

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

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

五、三方合并的决策规则

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

共同祖先	Ours（当前分支）	Theirs（目标分支）	Git 的决策
A	A（未改）	B（改了）	采用 B
A	B（改了）	A（未改）	采用 B
A	B（改了）	C（也改了，但不同）	冲突！
A	B（改了）	B（改了，且相同）	采用 B
A	A（未改）	A（未改）	保持 A

规则总结

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

六、冲突（Conflict）

什么时候产生冲突

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

冲突标记

复制代码

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

解决冲突

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

七、合并提交（Merge Commit）

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

复制代码

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

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

查看合并提交的父提交

bash 复制代码

git log -1 --format="%P" <merge_commit>

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

注：

博客：

https://blog.csdn.net/badao_liumang_qizhi

八、实际场景分析

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

复制代码

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

合并时的三方对比：

共同祖先（master 3月状态）	你的分支	dev
`Integer count = ...`	`Integer count = ...`	`Long count = ...`

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

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

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

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

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

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

九、合并策略选项

recursive（默认）

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

ours

bash 复制代码

git merge -s ours feature

完全忽略对方的修改，保留当前分支的所有内容。

theirs（通过选项实现）

bash 复制代码

git merge -X theirs feature

冲突时自动选择对方的版本。

十、最佳实践

频繁同步：定期将目标分支（dev/main）合并到你的 feature 分支，减少最终合并时的差异
从正确的分支拉取：如果要合并到 dev，就从 dev 拉分支，而不是从 master
小步提交：每次提交的改动尽量小且聚焦，减少冲突范围
合并前先拉取最新 ：git fetch + git merge 确保本地是最新状态
合并后立即验证：编译、运行测试，确保合并结果正确

十一、总结

三方合并的核心思想：

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

理解了这个原理，你就能理解为什么合并后代码会"自动变化"------不是 Git 出了问题，而是它正确地执行了三方合并的逻辑。