Git三方合并策略完整指南

平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“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 <branch1> <branch2>

这个命令会输出共同祖先的 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" <merge_commit>

实际处理时，输出两个 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 出了问题，而是它正确地执行了三方合并的逻辑。

从实现思路看，总的来说，Git三方合同时策略适合结合实际项目边做边理解。先抓住核心思路，再逐步补上细节和边界处理，最后效果会更稳定，也更容易复用。