Git 中的 Rebase 与 Merge：原理、区别与最佳实践

1. 引言：为什么 Git 会有 rebase 和 merge 两种方式？

在团队开发中，我们经常会遇到这样的场景：

• 多个人在同一个仓库并行开发
• 主分支（main / master）在不断前进
• 自己的功能分支需要同步最新代码

这时，Git 给我们提供了两种选择：

• git merge
• git rebase

它们都能“合并代码”，那到底有什么区别？

2. Git Merge：保留真实历史的合并

2.1 Merge 的基本思想

merge的核心思想是：

把两个分支的历史“汇合”在一起，并生成一个新的合并提交。

示意图如下：

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

合并后：

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

其中M是一个Merge Commit。

2.2 Merge 的使用方式

gitcheckout maingitmerge feature

注意要合并的时候切换到目标分支

2.3 Merge 的优点

• 不修改历史，绝对安全
• 提交记录完整可追溯
• 适合多人协作、公共分支

2.4 Merge 的缺点

• 提交历史可能出现大量 merge commit
• 日志图可能较为“杂乱”
• 不利于线性回溯提交

3. Git Rebase：重写历史的“整理术”

3.1 Rebase 的基本思想

rebase的核心思想是：

把当前分支的提交“挪到”另一个分支的最新提交之后。

示意图：

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

Rebase 后：

A---B---C---D---E'---F' (feature)

注意：

• E'、F'是新提交
• 原来的E、F已被替换

3.2 Rebase 的使用方式

gitcheckout featuregitrebase main

3.3 Rebase 的优点

• 提交历史线性、干净
• 更容易阅读和回滚
• 非常适合整理本地提交

3.4 Rebase 的缺点

• 会重写提交历史
• 如果操作不当，容易引发协作问题
• 不适合已经推送到远程的公共分支

4. Rebase 与 Merge 的核心区别

操作位置对比

5. 冲突处理上的区别

Merge 冲突

• 只解决一次冲突
• 生成一个 merge commit

Rebase 冲突

• 每一个提交都可能冲突
• 需要多次git rebase --continue

6. 一个重要原则

❗永远不要 rebase 已经推送到远程的公共分支

原因：

• 会改变提交 hash
• 导致他人无法正常拉取代码
• 可能引发灾难性冲突

7. 实战推荐用法

场景 1：个人功能分支

✅ 推荐 rebase

gitcheckout featuregitrebase main

目的：
👉 保持提交历史干净

场景 2：合并到主分支

✅ 推荐 merge

gitcheckout maingitmerge feature

目的：
👉 保留真实开发历史

场景 3：提交前整理 commit

gitrebase -i HEAD~3

可用于：

• 合并提交
• 修改提交信息
• 删除无用提交

8. GitHub / GitLab 的最佳实践

• 功能开发：rebase同步主分支
• 最终合并：merge或squash merge
• 禁止对main/master执行 rebase

参考

【五分钟学会git rebase和 git merge的区别】

Git：图解 merge 和 rebase 的区别