Git Merge vs Rebase 底层逻辑、适用场景与操作指南

合并完成后，执行 git log --oneline --graph 查看提交历史，输出如下：

* 45f8d21 (HEAD -> main, feature/docs) docs: add quick start guide
* a7c3d90 chore: init project

可以看到，main 分支的指针直接移动到了 feature/docs 分支的最新提交，没有生成任何新的合并提交，提交历史完全线性。

2.1.2 Three-Way Merge 三方合并

这是 Merge 最常用的场景，当两个分支满足：目标分支和特性分支，在分出之后都有了新的提交，此时两个分支的历史出现了分叉，无法执行快进合并，Git 会自动执行三方合并。

三方合并的核心逻辑，是 Git 会自动找到 3 个关键提交节点：

1. 待合并的两个分支的最新提交（main 的 HEAD 和 feature 的 HEAD）
2. 两个分支的最近共同祖先 LCA（Lowest Common Ancestor）

基于这 3 个节点，Git 会对比两个分支相对于共同祖先的差异，自动合并差异内容，最终生成一个全新的合并提交（Merge Commit）。这个合并提交有一个特殊的结构：它有两个 parent 指针，分别指向两个待合并分支的最新提交，以此完整保留两个分支的开发历史。

执行以下命令可完整复现三方合并场景：

# 基于上面的仓库，重置 main 分支到初始提交
git reset --hard a7c3d90
# 删除旧的特性分支
git branch -D feature/docs
# 重新创建特性分支
git checkout -b feature/login
# 特性分支第一次提交
mkdir src
echo "// user login core logic" > src/login.js
git add src/login.js
git commit -m "feat: add login core logic"
# 特性分支第二次提交
echo "// login input validation" >> src/login.js
git add src/login.js
git commit -m "feat: add login validation"
# 切回 main 分支，提交新内容，制造分叉
git checkout main
echo "// project base config" > config.js
git add config.js
git commit -m "chore: add base config"
# 执行三方合并
git merge feature/login

如果没有冲突，Git 会自动生成合并提交，并打开编辑器让你填写合并提交信息，默认信息为 Merge branch 'feature/login'。合并完成后，执行 git log --oneline --graph 查看历史，输出如下：

*   3f7e2d1 (HEAD -> main) Merge branch 'feature/login'
|
| * 2c8d3f4 (feature/login) feat: add login validation
| * 7d9e4f5 feat: add login core logic
* | 5a6b7c8 chore: add base config
|
* a7c3d90 chore: init project

可以清晰看到，提交历史出现了分叉，合并提交有两个父节点，完整保留了两个分支的所有开发轨迹。

2.2 Merge 的核心特性

1. 绝对不修改现有提交历史：所有已存在的提交的哈希值、内容、父节点都不会有任何变化，只会新增合并提交，这是 Merge 最大的优势，也是协作安全性的核心保障
2. 完整保留开发轨迹：合并提交的双父节点结构，完整记录了分支的分叉和合并过程，可追溯性极强，方便后续排查问题和回滚
3. 冲突仅需解决一次：无论两个分支有多少差异，只需要在生成合并提交时解决一次冲突，操作成本低
4. 分支历史会出现分叉：多次合并后，提交历史会出现大量分叉，长期下来会变成'蜘蛛网'，可读性变差

2.3 Merge 的核心参数与高频用法

1. --no-ff：强制关闭快进合并，即使可以快进，也强制生成合并提交。这是企业级团队最常用的参数，能完整保留特性分支的开发轨迹，方便后续回滚和追溯，示例：git merge --no-ff feature/login
2. --squash：压缩合并，将特性分支的所有提交压缩成一个新的提交，合并到目标分支，不会保留特性分支的提交历史，也不会生成双父节点的合并提交，适合清理临时分支的零散提交
3. --abort：合并出现冲突时，终止合并操作，恢复到合并前的状态

三、Git Rebase 深度解析：线性化历史的变基操作

Git Rebase 的官方定义是：在另一个基础提交的顶端，重新应用一系列提交。它的核心设计目标是：重新设置分支的基准节点，将分叉的提交历史线性化，保持提交历史的整洁可读。

3.1 Rebase 的底层执行逻辑

很多人对 Rebase 的理解停留在'让提交历史变直'，但没有搞懂它的底层操作，这也是绝大多数坑的根源。

Rebase 的核心逻辑，拆解为 5 个不可拆分的步骤：

1. Git 自动找到当前分支与目标分支的最近共同祖先 LCA
2. 提取当前分支中，LCA 之后的所有提交，将每个提交的差异内容生成临时补丁文件
3. 将当前分支的指针，直接指向目标分支的最新提交（也就是重新设置分支的'基准'）
4. 按照原始提交的顺序，逐个将临时补丁应用到新的基准节点上，每应用一个补丁，就生成一个全新的提交

所有补丁应用完成后，变基操作结束，当前分支的提交历史变成完全线性的结构。

这里的核心关键点，也是和 Merge 最本质的区别：Rebase 会重写提交历史，LCA 之后的所有原始提交都会被废弃，生成全新的提交，即使内容完全不变，提交的哈希值也会完全改变，因为新提交的父节点、元数据都发生了变化。

3.2 Rebase 基础实战示例

我们用和上面三方合并完全相同的仓库场景，来演示 Rebase 的操作，让你直观看到和 Merge 的区别：

# 基于之前的仓库，重置 main 分支到初始提交
git reset --hard a7c3d90
# 删除旧的特性分支
git branch -D feature/login
# 重新创建特性分支，和 Merge 示例完全一致的提交
git checkout -b feature/login
mkdir src
echo "// user login core logic" > src/login.js
git add src/login.js
git commit -m "feat: add login core logic"
echo "// login input validation" >> src/login.js
git add src/login.js
git commit -m "feat: add login validation"
# 切回 main 分支，提交新内容，制造完全一致的分叉
git checkout main
echo "// project base config" > config.js
git add config.js
git commit -m "chore: add base config"
# 切回特性分支，执行 Rebase 操作，目标基准是 main 分支
git checkout feature/login
git rebase main

如果没有冲突，Rebase 会自动完成所有补丁的应用，执行完成后，执行 git log --oneline --graph 查看特性分支的提交历史，输出如下：

* 8d9e0f1 (HEAD -> feature/login) feat: add login validation
* 7c6d5b4 feat: add login core logic
* 5a6b7c8 (main) chore: add base config
* a7c3d90 chore: init project

可以看到，特性分支的提交历史变成了完全线性的结构，没有任何分叉，原本的两个提交，现在生成了两个全新的提交，哈希值和之前完全不同，它们的父节点变成了 main 分支的最新提交，相当于把特性分支的开发，'嫁接'到了 main 分支的最新提交之后。

此时，我们只需要切回 main 分支，执行快进合并，就能把特性分支的内容合并进来，不会生成任何合并提交，main 分支的历史也会保持完全线性：

git checkout main
git merge feature/login

合并完成后，main 分支的提交历史如下：

* 8d9e0f1 (HEAD -> main, feature/login) feat: add login validation
* 7c6d5b4 feat: add login core logic
* 5a6b7c8 chore: add base config
* a7c3d90 chore: init project

3.3 Rebase 冲突处理

Rebase 在逐个应用补丁的过程中，如果遇到冲突，会暂停当前的变基操作，提示冲突文件，此时你需要遵循以下正确步骤处理，90% 的开发者在这里都会操作错误：

1. 打开冲突文件，手动解决所有冲突内容
2. 解决完成后，执行 git add <冲突文件>，将修改后的文件加入暂存区
3. 执行 git rebase --continue，继续应用下一个补丁，绝对不要执行 git commit
4. 如果想中途放弃变基，恢复到变基前的状态，执行 git rebase --abort

这里必须强调：Rebase 的冲突是逐个提交处理的，如果你的特性分支有 10 个提交，可能需要解决 10 次冲突，这是 Rebase 的一个缺点；而 Merge 只需要解决一次冲突。

3.4 Rebase 的核心特性

1. 提交历史完全线性化：彻底消除分支分叉，提交历史是一条干净的直线，可读性极强，方便后续代码评审、日志排查
2. 重写提交历史：会废弃原始提交，生成全新的提交，改变提交哈希值，这是 Rebase 最大的风险点
3. 无额外合并提交：不会生成 Merge Commit，避免了大量合并提交污染提交历史
4. 原子性提交可保障：配合交互式变基，可以整理零散的提交，确保每个提交都是原子性的，有明确的功能边界

3.5 Rebase 的高频进阶用法：交互式变基（git rebase -i）

交互式变基是 Git 提供的超强功能，也是企业级开发中最常用的 Rebase 场景，它可以让你在变基的过程中，修改、合并、删除、重新排序提交，彻底整理你的本地提交历史。

它的基础用法是：git rebase -i <目标提交>，其中目标提交是你要整理的提交范围的父提交，比如 git rebase -i HEAD~3，就是整理最近 3 个提交。

执行命令后，Git 会打开编辑器，列出你要整理的所有提交，每个提交前面有一个操作命令，默认是 pick，你可以修改命令来实现不同的操作，核心命令如下：

实战示例：合并最近 2 个零散的提交，整理成一个完整的功能提交

# 基于上面的 feature/login 分支，执行交互式变基
git checkout feature/login
git rebase -i HEAD~2

执行后，编辑器会打开如下内容：

pick 7c6d5b4 feat: add login core logic
pick 8d9e0f1 feat: add login validation
# 命令说明...

我们将第二个提交的命令改为 squash，修改后如下：

pick 7c6d5b4 feat: add login core logic
squash 8d9e0f1 feat: add login validation

保存退出后，Git 会打开新的编辑器，让你填写合并后的提交信息，修改为 feat: complete user login function with validation，保存后完成变基。

执行 git log --oneline 查看，原本的 2 个提交已经合并成了 1 个完整的提交，提交历史更加整洁。

四、Merge vs Rebase 核心差异全对比

我们用一张表格，从核心维度，彻底区分 Merge 和 Rebase 的区别，所有内容均基于 Git 官方定义，100% 准确：

五、核心红线与适用场景：再也不会用错的决策标准

这是本文最核心的部分，也是 90% 的开发者踩坑的根源。Merge 和 Rebase 没有绝对的优劣，只有是否适合场景，用对了事半功倍，用错了灾难连连。

5.1 不可逾越的核心红线（Git 官方明确警告）

永远不要对已经推送到公共远程仓库、且有其他协作者基于其开发的提交，执行 Rebase 操作！

这是 Git 官方文档中明确标注的最高优先级警告，没有任何例外。

原因非常简单：你对公共分支执行 Rebase 后，重写了提交历史，远程仓库的提交哈希发生了变化，而其他协作者的本地仓库，还是基于旧的提交历史开发的。当他们执行 pull 操作时，Git 会把两个不同的历史合并，生成大量重复的提交，最终导致整个仓库的提交历史彻底混乱，甚至丢失代码。

即使你用 git push --force 强制覆盖了远程分支，也无法解决这个问题，只会让灾难扩散。唯一的补救方式，是让所有协作者都删除本地的对应分支，重新拉取远程的新分支，这在多人协作的团队中，成本极高，极易引发代码丢失。

5.2 什么时候必须用 Merge？

满足以下任意一个场景，优先选择 Merge，绝对不要用 Rebase：

1. 将特性分支合并回公共主干分支（main/develop）：这是 Merge 最核心的使用场景。无论是 GitHub PR、GitLab MR，合并到公共主干时，用 Merge（推荐 --no-ff 参数）可以完整保留特性分支的开发历史，保证主干分支的历史可追溯，回滚方便，且不会修改任何现有提交，绝对安全。
2. 多人协作的共享分支合并：只要是多个开发者同时在开发的分支，合并时必须用 Merge，禁止用 Rebase，避免重写公共历史。
3. 需要完整保留开发轨迹的合规场景：很多企业有合规要求，需要完整记录代码的开发、合并、修改全流程，Merge 的完整历史可以满足这个要求，而 Rebase 会抹除原始开发轨迹。
4. 合并多个分支的复杂场景：当需要一次性合并多个分支时，Merge 的 octopus 策略可以轻松处理，而 Rebase 无法实现。

5.3 什么时候可以用 Rebase？

满足以下所有前提条件，才可以使用 Rebase，缺一不可：

1. 操作的分支是你自己的本地私有分支：没有推送到远程仓库，或者推送到了远程，但只有你一个人在使用，没有任何其他协作者基于这个分支开发
2. 你要重写的提交，没有被合并到任何公共分支

满足前提的情况下，以下场景是 Rebase 的最佳实践：

3. 同步公共主干分支的最新提交到本地特性分支：当你在本地开发特性分支时，主干分支有了新的提交，你需要同步这些提交来解决冲突、避免后续合并出现问题。此时用 git rebase main，可以把你的特性分支'嫁接'到主干的最新提交上，保持提交历史线性，避免生成无意义的合并提交。
4. 整理本地私有分支的提交历史：开发过程中，你可能会生成很多零散的提交，比如'fix: typo''wip: 临时提交'，在提交 PR/MR 之前，用交互式变基 git rebase -i 整理这些提交，合并零散提交、修改提交信息、删除无用提交，让每个提交都是原子性的、有明确意义的，方便代码评审。
5. 线性化本地分支历史，提升可读性：对于你自己的私有分支，用 Rebase 保持提交历史线性，方便后续排查问题、回溯代码修改。
6. 提交 PR/MR 之前，解决与主干的冲突：在提交代码评审之前，用 Rebase 同步主干最新代码，解决所有冲突，确保评审的代码是基于最新主干的，避免评审完成后合并时出现冲突。

5.4 绝对禁止使用 Rebase 的场景

1. 任何公共分支（main/develop/release 等），绝对禁止执行 Rebase
2. 已经推送到远程仓库、且有其他协作者使用的分支，绝对禁止执行 Rebase
3. 已经合并到公共主干的提交，绝对禁止执行 Rebase
4. 多人协作的共享分支，绝对禁止执行 Rebase

六、高频误区与易混淆点避坑

这里整理了开发者最容易踩的 10 个误区，100% 纠正错误认知，避免踩坑：

误区 1：Rebase 会丢失提交历史，Merge 不会

纠正：Rebase 不会丢失任何提交内容，它只是把原始提交废弃，生成了全新的提交，所有的代码修改都会完整保留，只是提交的哈希值和父节点变了，历史变成了线性的。Merge 保留的是分叉的原始历史，Rebase 保留的是线性的修改历史，两者都不会丢失代码内容。

误区 2：Rebase 比 Merge 高级，用 Rebase 就是更专业

纠正：Merge 和 Rebase 只是两个不同的工具，有不同的适用场景，没有高低优劣之分。用对了场景，两个都是专业的操作；用错了场景，哪怕是 Rebase，也是灾难性的错误。很多资深开发者，在公共分支合并时，永远只用 Merge，因为安全永远是第一位的。

误区 3：Fast-Forward 合并和 Rebase 的结果是一样的

纠正：两者的最终提交历史看起来都是线性的，但底层逻辑完全不同。Fast-Forward 合并只是移动了分支指针，没有修改任何提交，所有提交的哈希值完全不变；而 Rebase 是生成了全新的提交，哈希值完全改变，原始提交被废弃。

误区 4：对公共分支 Rebase 后，只要强制推送就行

纠正：对公共分支执行 Rebase 后，哪怕用 git push --force 强制覆盖了远程分支，也无法解决根本问题。其他协作者的本地分支还是基于旧的历史，他们 pull 的时候会生成大量重复提交，导致历史彻底混乱。唯一正确的做法，是永远不要对公共分支执行 Rebase。如果非要修改已经推送的公共分支提交，必须用 git revert 生成反向提交，而不是 Rebase。

误区 5：git pull 的默认行为是 Rebase

纠正：git pull 的默认行为是 git fetch + git merge，也就是先拉取远程分支的最新内容，然后用 Merge 合并到本地分支。如果你想让 pull 的时候默认用 Rebase，可以执行配置命令：git config --global pull.rebase true，这也是很多团队的推荐配置，可以避免本地分支生成大量无意义的合并提交。

误区 6：Merge 的--squash 参数和 Rebase 的 fixup 是一样的

纠正：git merge --squash 是将特性分支的所有提交压缩成一个新的提交，合并到目标分支，不会保留特性分支的提交历史，也不会生成双父节点的合并提交；而 Rebase 的 fixup 是在变基的过程中，将提交合并到上一个提交，是在同一个分支内整理提交历史，两者的使用场景和底层逻辑完全不同。

误区 7：Rebase 之后，原始提交就彻底消失了

纠正：Rebase 之后，原始提交只是没有被分支指针指向了，并没有被立即删除。Git 有 reflog 机制，会记录所有分支指针的变化，你可以通过 git reflog 找到原始提交的哈希值，在 30 天内（Git 默认的过期时间）都可以恢复。

误区 8：合并冲突的时候，Rebase 和 Merge 的处理方式是一样的

纠正：Merge 冲突解决完成后，需要执行 git commit 生成合并提交；而 Rebase 冲突解决完成后，需要执行 git add，然后 git rebase --continue，绝对不能执行 git commit，否则会生成额外的提交，导致变基失败。

误区 9：Rebase 可以替代 Merge

纠正：绝对不能。Rebase 只能处理私有分支的历史整理和同步，无法替代 Merge 在公共分支合并中的作用。任何团队，都不可能只用 Rebase 不用 Merge，否则协作一定会出问题。

误区 10：三方合并就是简单的两个分支内容对比覆盖

纠正：Git 的三方合并，是基于共同祖先的差异合并，不是简单的覆盖。Git 会对比两个分支相对于共同祖先的修改，只要两个分支修改的不是同一行代码，Git 会自动合并；只有修改了同一行代码，才会提示冲突。这也是 Git 合并能力强大的核心原因。

七、企业级团队协作最佳实践

基于 Git 官方推荐，结合业界主流的 Git Flow、GitHub Flow、GitLab Flow 规范，我们整理了一套可直接落地的、零坑的合并策略最佳实践，无论是小团队还是大型企业，都可以直接使用：

7.1 分支管理与合并策略匹配规范

7.2 提交历史管理规范

1. 本地开发过程中，允许生成临时提交，但在提交 PR/MR 之前，必须用交互式变基整理提交历史，确保每个提交都是原子性的，一个提交只做一件事，提交信息符合 Conventional Commits 规范
2. 禁止将多个不相关的功能修改，放在同一个提交中
3. 禁止在主干分支中生成无意义的合并提交，所有合并到主干的操作，都必须有明确的合并目的

7.3 远程操作规范

1. 绝对禁止对公共分支执行 git push --force，仅允许对自己的私有特性分支，使用 git push --force-with-lease 强制推送，--force-with-lease 会检查远程分支是否有新的提交，避免覆盖其他人的修改，比--force 安全得多
2. 拉取远程分支更新时，推荐使用 git pull --rebase，或者配置全局默认 pull 用 rebase，避免本地分支生成大量无意义的合并提交
3. 推送代码之前，必须先拉取远程分支的最新更新，解决所有冲突，再推送

7.4 冲突处理规范

1. 合并冲突必须由代码的修改人亲自解决，禁止不看代码直接用--ours 或--theirs 覆盖
2. 解决冲突后，必须编译测试通过，再继续合并或变基操作
3. Rebase 过程中，如果冲突过多，难以解决，可以执行 git rebase --abort 放弃变基，改用 Merge 合并

7.5 代码评审与合并规范

1. PR/MR 提交之前，必须先 Rebase 同步主干的最新代码，解决所有冲突，确保评审的代码是基于最新主干的
2. 代码评审通过后，由项目负责人执行合并操作，必须使用 git merge --no-ff，禁止快进合并，确保完整保留特性分支的开发轨迹
3. 合并完成后，及时删除已经合并的远程特性分支，避免分支冗余

八、最终总结

回到最开始的灵魂拷问：到底用 Merge 还是 Rebase？

答案非常简单，记住两句话就够了： 公共分支合并用 Merge，安全完整可追溯；私有分支整理用 Rebase，干净线性易阅读。

Git Merge 和 Rebase，不是对立的两个选项，而是互补的两个工具。Merge 的核心价值是安全和可追溯，是团队协作的基础保障；Rebase 的核心价值是整洁和灵活，是本地开发的效率工具。

你不需要盲目跟风用 Rebase，也不用无脑只用 Merge，只要理解了它们的底层逻辑，守住了公共分支不用 Rebase 的核心红线，根据场景选择合适的工具，就能把 Git 用得得心应手，再也不会因为合并操作踩坑。

最后，再强调一遍 Git 官方的最高警告：永远不要重写已经公开的提交历史！

参考资料

1. Git 官方文档 - git-merge: https://git-scm.com/docs/git-merge
2. Git 官方文档 - git-rebase: https://git-scm.com/docs/git-rebase
3. Git 官方 Pro Git 书籍 - 分支与变基：https://git-scm.com/book/en/v2/Git-Branching-Rebasing
4. Git 官方文档 - 交互式变基：https://git-scm.com/docs/git-rebase#_interactive_mode