深入理解 git rebase：何时使用、何时避免以及常见陷阱

引言

在 Git 的日常使用中，git merge 和 git rebase 是两种最常见的分支整合方式。相比 merge 保留完整的分叉历史，rebase 通过重写提交历史来创造一条线性的提交记录。这种"改写历史"的能力既是它最大的优势，也是它最大的风险来源。本文将从原理出发，系统梳理 git rebase 的适用场景、应当回避的情形，以及实践中容易踩到的坑。

一、rebase 到底做了什么

理解 rebase 的关键在于一句话：它并不是"移动"提交，而是"重新应用"提交。

假设你有如下历史：

      A---B---C  feature
     /
D---E---F---G  main

在 feature 分支执行 git rebase main 后，Git 会：

1. 找到 feature 与 main 的共同祖先 E；
2. 提取 E 之后 feature 上的每个提交（A、B、C）所对应的补丁；
3. 将这些补丁依次应用到 main 的最新提交 G 之上；
4. 生成三个全新的提交 A'、B'、C'（哈希值完全不同），并将 feature 指向 C'。

结果变成：

              A'--B'--C'  feature
             /
D---E---F---G  main

由于提交被重新创建，原始提交对象仍然存在于仓库中（直到被 GC 回收），但分支引用已不再指向它们。这正是 rebase 会"改写历史"的根本原因，也是所有注意事项的出发点。

二、何时应该使用 rebase

1. 同步上游分支，保持本地历史整洁

当你在一个长期存在的 feature 分支上工作时，主分支可能已经前进了不少。此时用 git rebase main 把 feature 的提交"搬"到 main 最新提交之上，可以避免反复出现无意义的合并提交，让历史保持线性、易读。

2. 整理本地提交，提交前"梳妆打扮"

在推送之前，用交互式 rebase（git rebase -i）合并琐碎的 WIP 提交、修改提交信息、调整提交顺序，甚至把一个大提交拆分成多个逻辑提交。这是 rebase 最有价值的用法之一：

git rebase -i HEAD~5

在编辑器中你可以对每个提交执行 pick、squash、reword、edit、drop 等操作，把一团乱麻整理成清晰的提交序列。

3. 在个人分支上追平远程更新

如果 feature 分支是你一个人在开发，且尚未推送到共享分支，那么在合并前 rebase 到最新的 main 是完全安全的。

4. 使用 --autosquash 配合 fixup 提交

开发中常用 git commit --fixup=<hash> 记录临时修补，之后用 git rebase -i --autosquash 自动把它们折叠到对应的原始提交中，非常适合在 code review 后整理补丁。

三、何时应当避免 rebase

1. 已推送到共享分支的提交

这是最经典的"铁律"：不要 rebase 任何已经被其他人拉取过的提交。因为 rebase 会生成新的哈希，其他人本地的历史会与远程产生分叉，他们不得不做一次痛苦的强制合并，甚至可能丢失工作。

如果确实需要 rebase 一个已推送的分支，必须使用 git push --force-with-lease（而非 --force），并提前通知所有协作者。

2. 主干分支（main / master / develop）

在主干分支上执行 rebase 会重写所有人的共同基础，几乎必然导致灾难。主干分支应当只接受 merge 或 fast-forward。

3. 需要保留真实合并历史的场景

某些团队或开源项目（如 Linux 内核）刻意保留合并提交，以记录"某个功能是在何时、以何种方式并入主线的"。这类场景下 rebase 会抹掉有价值的历史信息，应当使用 merge。

4. 多人协作的同一分支

即使分支尚未合并，只要有多人在上面工作，rebase 就会给他人带来麻烦。此时更稳妥的做法是 merge 上游变更。

四、常见陷阱与应对

陷阱 1：冲突反复出现

rebase 是逐个提交应用补丁，因此同一个冲突可能在多个提交中反复出现，解决起来比 merge 更累。应对方法：

• 使用 git rerere（reuse recorded resolution）自动复用冲突解决方案；
• 或先 git merge 一次上游，解决冲突后再考虑是否需要 rebase。

陷阱 2：--force 覆盖他人提交

git push --force 会无条件覆盖远程分支。如果同事在此期间推送了新提交，这些提交会被静默丢弃。始终使用 --force-with-lease，它会在远程分支与你预期不一致时拒绝推送：

git push --force-with-lease

陷阱 3：丢失提交

rebase 过程中如果操作失误（比如误用 drop，或解决冲突时 --skip 了不该跳过的提交），提交可能"消失"。好在 Git 有 reflog：

git reflog
git reset --hard HEAD@{n}

只要没执行 git gc，几乎总能找回。养成在大型 rebase 前打一个备份分支的习惯：

git branch backup-before-rebase

陷阱 4：误用 git rebase --onto

--onto 是强大但容易误用的选项。它允许你把一段提交"移植"到任意基点：

git rebase --onto main feature-base feature

含义是：把 feature-base..feature 范围内的提交，重新应用到 main 上。用错基点会导致提交丢失或历史错乱，使用前务必用 git log --oneline 确认范围。

陷阱 5：合并提交被"压平"

默认情况下，rebase 会丢弃合并提交，把它们的内容展开为普通提交。如果确实需要保留合并结构，要加上 --rebase-merges（旧版本为 --preserve-merges）：

git rebase --rebase-merges main

陷阱 6：在 rebase 中途慌乱操作

rebase 遇到冲突时会暂停，此时你处于一个"分离头指针"的中间状态。常见的正确操作是：

• 解决冲突后 git add，然后 git rebase --continue；
• 想放弃整个 rebase：git rebase --abort；
• 想跳过当前提交：git rebase --skip（慎用）。

切忌在此时直接 git commit 或切换分支，否则会陷入更混乱的状态。

五、实践建议小结

1. 黄金法则：只 rebase 尚未共享的本地提交。
2. 推送用 --force-with-lease，永远不用裸 --force。
3. 大型 rebase 前打备份分支，出问题用 reflog 兜底。
4. 交互式 rebase 是整理提交的利器，但不要在公共分支上使用。
5. 团队约定优先：有的团队偏好线性历史（多用 rebase），有的偏好保留合并记录（多用 merge）。工具没有对错，约定才重要。

结语

git rebase 是一把双刃剑：它能让历史如散文般流畅，也能在误用时把协作搅成一团乱麻。理解它"重新应用补丁、生成新提交"的本质，就能在"整理本地历史"与"尊重共享历史"之间划出清晰界限。掌握本文列出的场景与陷阱，你就能在需要时自信地使用 rebase，在该回避时果断选择 merge。

未经允许不得转载：任鹏个人博客 » 深入理解 git rebase：何时使用、何时避免以及常见陷阱