Git三方合并策略详解

目录

• 一、什么是合并（Merge）
• 二、快进合并（Fast-Forward Merge）
• 场景
• 特点
• 三、三方合并（Three-Way Merge）
• 什么时候触发
• 三方合并的"三方"是什么
• 为什么需要共同祖先
• 四、共同祖先（Merge Base）
• 定义
• 图示
• 查找共同祖先
• 复杂场景：多次合并后的共同祖先
• 五、三方合并的决策规则
• 规则总结
• 六、冲突（Conflict）
• 什么时候产生冲突
• 冲突标记
• 解决冲突
• 七、合并提交（Merge Commit）
• 查看合并提交的父提交
• 八、实际场景分析
• 场景：从旧分支合并到已更新的目标分支
• 场景：你修改了同一行附近的代码
• 场景：你的分支不是从 dev 拉的
• 九、合并策略选项
• recursive（默认）
• ours
• theirs（通过选项实现）
• 十、最佳实践
• 十一、总结

在 Git 中，合并是将两条独立的开发线（分支）的修改整合到一起的操作。当你执行 git merge 时，Git 需要决定如何将两个分支的代码变更合并为一个最终结果。

在了解三方合并之前，先了解最简单的合并方式。

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

如果 main 分支在你创建 feature 分支后没有任何新提交，合并时 Git 只需要把 main 的指针直接移动到 feature 的最新提交即可：

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

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

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

当两个分支都有各自的新提交时，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 的修改

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

         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 <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

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

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

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

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

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

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

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

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 修改的部分也保留
• 如果两者修改了同一行 → 产生冲突

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

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

git merge -s ours feature

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

git merge -X theirs feature

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

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

三方合并的核心思想：

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

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

以上就是Git三方合并策略详解的详细内容，更多关于Git三方合并策略的资料请关注风君子博客其它相关文章！

您可能感兴趣的文章:

• Git实现将一个分支的特定提交合并到另一个分支
• Gitlab合并代码并解决冲突的问题
• Gitlab实现合并分支代码到主分支上
• Git合并多个提交实现方式
• GIT合并分支的三种实现方式