前言

在日常的 Git 开发工作中，我们经常需要将一个分支的修改合并到另一个分支。Git 提供了两种主要的合并策略：merge 和 rebase。很多开发者（包括我之前）在使用时往往只是机械地选择merge，而不理解它们背后的原理和适用场景。

本文将深入解析 merge 和 rebase 的工作原理，对比二者的区别，并给出实际应用场景的建议。

一、Merge：保留完整历史的合并方式

1.1 Merge 的工作原理

**Merge（合并）**是 Git 最传统、最直观的分支合并方式。当我们执行 git merge 命令时，Git 会做以下操作：

1. 找到两个分支的最近共同祖先（common ancestor commit）
2. 分别从共同祖先出发，对比两个分支上的所有更改
3. 自动合并没有冲突的文件
4. 如果有冲突，需要手动解决
5. 创建一个新的合并提交（merge commit）

关键点： merge 会创建一个新的提交节点，这个提交有两个父提交（两个分支的最新提交）。

Git 的 merge 分为两种：

• Fast-forward 快进合并：目标分支无新提交，直接移动指针，不生成新提交
• 三方合并（Three-way merge）：两个分支都有新提交，生成一个 merge commit

1.2 Merge 的可视化示例

假设我们有两个分支：main 和 feature，历史如下：

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

执行 git checkout main && git merge feature 后：

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

F 就是合并提交，它有两个父提交：C 和 E。

1.3 Merge 的特点

✅ 优点：

• 完整保留历史记录：所有分支信息都被保留，可清晰看到开发轨迹
• 非线性历史更真实：真实反映并行开发过程
• 安全性高：不会修改已存在提交，不破坏历史
• 易于回滚：合并操作可以轻松撤销

❌ 缺点：

• 频繁合并会让历史变得复杂、分叉多
• 提交树可读性下降，大型项目中历史会更臃肿

二、Rebase：重构提交历史的变基操作

2.1 Rebase 的工作原理

**Rebase（变基）**是一种重构提交历史的合并策略。当我们执行 git rebase 命令时，Git 会做以下操作：

1. 找到当前分支与目标分支的最近共同祖先
2. 将当前分支从共同祖先之后的所有提交提取为补丁
3. 将当前分支重置到目标分支的最新提交
4. 按顺序将这些补丁逐个重新应用
5. 生成全新的提交，提交 hash 全部改变

关键点： rebase 会重构历史，生成全新提交，原来的提交不再被当前分支引用。

2.2 Rebase 的可视化示例

同样初始结构：

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

执行 git checkout feature && git rebase main 后：

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

D’ 和 E’ 是 D、E 的全新副本，内容相同，但 hash 已改变。

原来的 D、E 仍然存在于仓库中，但不再属于 feature 分支。

2.3 Rebase 的特点

✅优点：

• 线性历史更清晰：一条直线，非常易读
• 无多余合并节点：不会产生 merge commit
• 提交日志更干净：看起来像顺序开发

❌缺点：

• 重构历史：改变已有提交的 hash
• 丢失原始分支上下文：无法看到真实并行开发结构
• 冲突需逐个解决：更繁琐
• 公共分支上使用极危险

三、Merge vs Rebase：核心区别对比

对比维度	Merge	Rebase
历史结构	非线性，保留分叉	线性，一条直线
是否创建新提交	创建 merge commit	不创建，重构历史
提交 hash	不改变	改变所有被变基的提交
冲突解决	一次性解决所有冲突	逐个提交解决冲突
安全性	安全，不修改历史	会改写历史，存在风险
历史完整性	完整保留并行信息	丢失原始分支结构
可读性	分支多时可读性差	线性历史，非常清晰
适用场景	公共分支、保留历史	个人私有分支、清理提交

四、冲突处理的差异（重要！）

4.1 Merge 的冲突处理

执行 git merge 时：

• 一次性对比所有改动
• 所有冲突集中展示
• 解决一次即可完成合并

优点：简单直接

缺点：冲突多时不易定位到具体提交

4.2 Rebase 的冲突处理

执行git rebase 时：

• Git 会逐个提交重新应用
• 遇到冲突就暂停
• 解决后必须用 git rebase --continue 继续

优点：冲突定位更精准

缺点：多次冲突要重复解决

操作示例：

git checkout feature
git rebase main

# 冲突出现
# 解决后
git add <文件>
git rebase --continue

# 放弃变基，恢复原状
git rebase --abort

五、何时使用 Merge？何时使用 Rebase？

5.1 使用 Merge 的场景

✅ 推荐使用 Merge：

1. 公共分支合并（main、develop 等）
2. 需要保留完整开发历史
3. 多人协作同一分支
4. 追求稳定、可追溯

示例：

git checkout main
git pull origin main
git merge feature
git push origin main

5.2 使用 Rebase 的场景

✅ 推荐使用 Rebase：

1. 个人私有功能分支
2. 同步主分支最新代码
3. 本地未推送提交，想清理历史
4. 准备提 PR 前整理提交

示例：

git checkout feature
git fetch origin
git rebase origin/main

# 解决冲突后推送（仅本地未共享时使用）
git push --force-with-lease

5.3 黄金法则

公共分支永远不要 rebase！

• 已推送到远程、被多人使用的分支：用 merge
• 仅自己使用、未共享的分支：可用 rebase

六、实际应用场景举例

场景1：功能开发完成，合并到主分支

使用 Merge

保留功能分支历史，方便回溯、回滚、Code Review。

场景2：开发中同步主分支最新代码

使用 Rebase

让你的 feature 分支始终基于最新 main，历史干净线性。

场景3：清理本地杂乱提交

使用交互式 Rebase

git rebase -i HEAD~4

可压缩、修改、重排、删除提交。

七、常见误区与注意事项

7.1 常见误区

• ❌ Rebase 比 Merge 高级 → 不是，只是适用场景不同。
• ❌ Merge 一定乱 → 规范使用下，merge 历史更真实。
• ❌ Rebase 会丢代码 → 不会，只是重构历史，内容不变。
• ❌ 只能二选一 → 团队最佳实践就是混用。

7.2 重要注意事项

⚠️ rebase 后必须谨慎强制推送

git push --force-with-lease  # 安全
git push --force             # 危险，可能覆盖他人代码

⚠️ 不确定是否被别人使用 → 不要 rebase

⚠️ Code Review 优先 merge，保留上下文更利于审查。

八、总结与建议

8.1 核心要点回顾

概念	Merge	Rebase
历史结构	非线性，保留分支	线性，干净整洁
是否新提交	是（merge commit）	否，重构历史
冲突处理	一次解决	逐个提交解决
安全性	安全	会改写历史
适用场景	公共分支	个人私有分支

8.2 实战工作流（最推荐）

1. 从 main 拉出功能分支
2. 开发中用 rebase 同步最新 main
3. 开发完通过 PR + merge合入 main

既干净又安全。

结语

Merge 与 Rebase 没有绝对优劣，只有场景是否合适。

• 要安全、真实、可追溯 → 用 Merge
• 要整洁、线性、清爽 → 用 Rebase（仅限私有分支）

永远记住：

不要 rebase 已经共享给别人的历史！

参考资料

1. Git 官方文档 - Git Branching - Rebasing