---

Git Rebase 使用指南：重塑提交历史的艺术与风险

Git 是现代软件开发中不可或缺的版本控制系统。掌握 Git 的各种高级用法，能够极大地提升开发效率和团队协作质量。在众多 Git 命令中，git rebase（变基）无疑是最强大、最灵活，同时也是最容易被误解和滥用，甚至可能造成灾难性后果的命令之一。

与更常用、更安全的 git merge（合并）命令不同，git rebase 的核心功能是“重写提交历史”。它可以帮助你整理、优化、甚至彻底改变你的提交序列，从而创造一个更清晰、更线性的项目历史记录。然而，正是因为“重写历史”这一特性，如果使用不当，特别是用在已经推送到共享仓库的提交上，可能会给团队协作带来巨大的麻烦。

本文将深入探讨 git rebase 的原理、用法、优势、风险以及最佳实践，帮助你充分利用这个强大工具，同时避开潜在的陷阱。

1. Git Merge vs. Git Rebase：核心差异

在深入学习 Rebase 之前，我们先快速回顾并对比一下 Git 中处理分支集成的两种主要方式：merge 和 rebase。理解它们的核心差异是理解 Rebase 的关键。

假设你有一个 main 分支，你从上面的 C1 提交创建了一个特性分支 feature，并在 feature 分支上进行了两次提交 (F1, F2)。同时，main 分支上也有了新的提交 (M1, M2)。

A---B---C1---M1---M2 (main)
\
F1---F2 (feature)

现在你想把 main 分支上的最新更改集成到你的 feature 分支，或者把你的 feature 分支的更改集成到 main 分支。

1.1 Git Merge (合并)

使用 git merge main 在 feature 分支上执行合并操作：

“`bash

假设当前在 feature 分支

git checkout feature
git merge main
“`

Merge 操作会找到 feature 分支和 main 分支的共同祖先（这里是 C1），然后创建一个新的“合并提交”（Merge Commit），这个提交有两个父节点，分别指向 feature 分别和 main 分支的最新提交。

A---B---C1---M1---M2 (main)
\ /
F1---F2---M (feature) <-- M 是合并提交

特点：

• 保留历史： Merge 操作不会改变现有提交的 SHA-1 值，它通过创建新的合并提交来记录分支的集成过程。原始的分支结构和提交顺序得以保留。
• 非线性历史： 合并提交的存在使得项目历史图看起来像一个“网”或“DAG”（有向无环图），分支的分叉和合并过程清晰可见。
• 简单安全： 对于已经共享出去的提交，Merge 是安全的选择，因为它不会改变公共历史。

1.2 Git Rebase (变基)

使用 git rebase main 在 feature 分支上执行变基操作：

“`bash

假设当前在 feature 分支

git checkout feature
git rebase main
“`

Rebase 操作的含义是：“把我的 feature 分支的起点（基）改变到 main 分支的当前最新提交”。它的过程大致是：

1. 找到 feature 分支和 main 分支的共同祖先（C1）。
2. 将 feature 分支上从共同祖先之后的所有提交（F1, F2）“提取”出来，暂时存放在一个临时区域。
3. 将 feature 分支的 HEAD 指针移动到 main 分支的最新提交 (M2)。
4. 将之前提取的提交（F1, F2）按顺序重新“应用”（apply）到 M2 之后。在应用过程中，Git 会比较差异并可能需要你解决冲突。应用成功后，会生成新的提交 (F1', F2')，它们包含了与 F1 和 F2 相同的代码更改，但 SHA-1 值不同。

A---B---C1---M1---M2 (main)
\
F1'---F2' (feature) <-- F1', F2' 是新的提交

特点：

• 重写历史： Rebase 会创建新的提交对象（F1', F2') 来代替原有的提交 (F1, F2)。这意味着提交的 SHA-1 值会改变。这是 Rebase 最核心也是最危险的特性。
• 线性历史： Rebase 使得分支历史看起来更加线性，仿佛所有开发都是在一条直线上进行的。这使得项目历史图更加整洁，更容易阅读。
• 提交优化： Rebase，尤其是交互式变基 (git rebase -i)，提供了在应用提交前修改它们的机会，比如合并（Squash）多个提交、编辑提交信息、删除提交等。

总结：

特性	Git Merge	Git Rebase
操作方式	创建新的合并提交	重写并重新应用原有提交
历史记录	保留原始提交，历史为“网状”结构	创建新的提交，历史为“线性”结构
提交 SHA	不改变现有提交 SHA-1	改变相关提交的 SHA-1
安全性	默认安全，不改变公共历史	危险，会改变历史，不应用于公共提交
主要用途	集成已共享的或重要分支的更改	清理、优化本地未共享的提交历史；保持特性分支与主分支同步

选择 Merge 还是 Rebase 取决于你的团队工作流程、分支策略以及你是否需要修改已经存在的提交历史。一般来说，对于已经推送到共享仓库的提交，永远不要使用 git rebase 去修改它们。 对于本地私有的特性分支，Rebase 可以是一个强大的历史清理工具。

2. 基本的 Git Rebase 使用

最常见的 Rebase 用途是将一个特性分支的起点移动到目标分支的最新状态，以便让你的特性分支包含目标分支的最新更改，并使得特性分支的历史看起来好像是从目标分支最新提交之后开始的。

假设你有以下分支结构：

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

现在 main 分支有了新的提交 F：

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

你想把 feature 分支变基到 main 分支上，以便你的 feature 分支包含 F 的改动，并且你的工作看起来是在 F 之后进行的。

步骤：

1. 切换到你要进行变基的分支（这里是 feature 分支）。
   bash
git checkout feature
2. 执行变基命令，指定目标分支（这里是 main 分支）。
   bash
git rebase main

Git 会执行以下操作：

1. 找到 feature 和 main 的共同祖先（B）。
2. 提取 feature 分支上在 B 之后的所有提交（D, E）。
3. 将 feature 分支的 HEAD 指针重置到 main 分支的最新提交 (F)。
4. 按顺序将提取的提交（D, E）重新应用到 F 之后，生成新的提交 D' 和 E'。

结果：

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

现在 feature 分支的历史是线性的，并且包含了 main 分支上 F 的所有更改。

2.1 处理 Rebase 过程中的冲突

在 Rebase 过程中，Git 会尝试一个接一个地应用你的提交。如果某个提交的更改与目标分支上的更改发生冲突，Git 会暂停 Rebase 过程，并在命令行中提示你解决冲突。

Applying: D
Using index info to reconstruct a base tree...
Falling back to patching three-way...
konfliktu: ... <-- 冲突信息

此时，你的文件系统中会包含冲突标记（<<<<<<<, =======, >>>>>>>）。你需要手动编辑文件，解决冲突，然后执行以下步骤：

1. 将解决冲突后的文件添加到暂存区。
   bash
git add <解决冲突的文件>
# 或者 git add . 来添加所有已解决冲突的文件
2. 继续 Rebase 过程。
   bash
git rebase --continue

Git 会继续尝试应用下一个提交。如果还有冲突，重复上述解决冲突和 --continue 的步骤。

如果你在解决冲突的过程中，发现情况复杂，或者后悔进行 Rebase，你可以随时中止 Rebase 过程，回到 Rebase 开始之前的状态：

bash
git rebase --abort

这将取消整个 Rebase 操作，你的分支会恢复到执行 git rebase 命令之前的状态。

3. 交互式 Git Rebase (git rebase -i)

交互式 Rebase 是 git rebase 最强大、最灵活的模式，它允许你在应用提交之前对它们进行各种修改。 -i 代表 interactive（交互式）。

使用场景：

• 在你准备将一个本地特性分支合并到主分支之前，清理这个特性分支的提交历史。
• 合并（Squash）多个相关的提交为一个。
• 拆分一个大型提交为多个小的提交。
• 修改提交信息。
• 删除不需要的提交（例如：WIP，fixup 等）。
• 调整提交的顺序。

如何使用：

你通常会变基到当前 HEAD 的某个祖先提交，或者变基到另一个分支上，同时指定 -i 选项。

• 变基到 HEAD 的前 N 个提交：
  bash
git rebase -i HEAD~N
  这会打开一个编辑器，列出 HEAD 前 N 个提交（不包括 HEAD 提交本身）。

• 变基到某个分支：
  bash
git rebase -i <目标分支>
  这会打开一个编辑器，列出当前分支相对于目标分支的所有提交。

示例：清理最近的 3 个提交

假设你最近有 3 个提交：

F2: Add button functionality
F1: Add button (WIP)
F0: Initial page structure
C: Previous commit on this branch/main

你觉得 F1 是一个临时的“Work In Progress”提交，应该和 F2 合并，并且 F0 的提交信息需要修改。

你可以执行：

bash
git rebase -i HEAD~3

Git 会打开你的默认文本编辑器，其中包含类似以下内容的列表：

“`
pick abcde F0: Initial page structure
pick fghij F1: Add button (WIP)
pick klmno F2: Add button functionality

Rebase edfgh..klmno onto edfgh (3 commands)

Commands:

p, pick = use commit

r, reword = use commit, but edit the commit message

e, edit = use commit, but stop for amending

s, squash = use commit, but meld into previous commit

f, fixup = like “squash”, but discard this commit’s log message

x, exec = run command (the rest of the line) after the previous commit

d, drop = discard the commit

These lines can be reordered; they are executed from top to bottom.

If you remove a line here THAT COMMIT WILL BE LOST.

However, if you remove everything, the rebase will be aborted.

Note that empty commits are commented out

“`

编辑器中的每一行代表一个提交，顺序是从旧到新（自上而下执行）。每行以一个命令开头，后面是提交的 SHA-1 和提交信息。

3.1 交互式 Rebase 命令详解

编辑器底部的注释部分解释了可用的命令：

• p, pick <commit>：使用该提交。这是默认操作，保持提交不变。
• r, reword <commit>：使用该提交，但在应用时暂停，让你编辑提交信息。
• e, edit <commit>：使用该提交，但在应用后暂停。这允许你修改该提交（例如，git commit --amend），进行额外的修改并创建新的提交，甚至将该提交拆分为多个提交。完成后，使用 git rebase --continue 继续。
• s, squash <commit>：使用该提交，并将其与前一个提交合并。Git 会合并这两个提交的更改，然后让你编辑一个新的合并提交信息。
• f, fixup <commit>：类似于 squash，但会丢弃当前提交的提交信息，直接使用前一个提交的提交信息（或者如果你要编辑前一个提交的信息，可以使用前一个提交的默认信息）。这用于将一些小的修改“合并”到之前的相关提交中，而不必写新的提交信息。
• x, exec <command>：在应用该提交后执行一个 shell 命令。
• d, drop <commit>：丢弃（删除）该提交。

3.2 实践示例 (使用上面的 F0, F1, F2 提交)

目标：合并 F1 到 F0 中，并修改 F0 的提交信息。

根据命令说明，我们想把 F1 和 F0 合并。squash 和 fixup 命令是将当前行代表的提交合并到它上面的提交中。所以我们需要调整提交的顺序，让 F1 在 F0 的下面。

修改编辑器中的内容如下：

pick fghij F1: Add button (WIP) <-- 把 F1 移到 F0 上面
reword abcde F0: Initial page structure <-- 使用 reword 命令来修改 F0 的提交信息
squash klmno F2: Add button functionality <-- 使用 squash 命令将 F2 合并到它上面的提交 (也就是 F0 和 F1 合并后的那个提交)

注意： 上面这个顺序和命令组合是错误的！因为 squash/fixup 是合并到前一个提交。正确的做法是先确定最终想要哪个提交作为基础（通常是保留最早的那个，然后把后面的合进来）。

让我们重新梳理一下目标：将 F1 和 F2 合并到 F0 的更改中，并修改最终的提交信息。

正确的方法是保留 F0，然后将 F1 和 F2 合并到 F0 里。

修改编辑器中的内容如下：

reword abcde F0: Initial page structure <-- 使用 reword 来修改 F0 的信息
squash fghij F1: Add button (WIP) <-- 将 F1 合并到 F0 中
squash klmno F2: Add button functionality <-- 将 F2 合并到 (F0+F1 合并后的) 提交中

或者，如果只想保留 F0 的原始信息，而将 F1 和 F2 的更改“修补”到 F0 中，可以使用 fixup（但不推荐，因为通常需要一个新的、更合适的提交信息）：

reword abcde F0: Initial page structure <-- 修改 F0 的信息
fixup fghij F1: Add button (WIP) <-- 将 F1 的更改合并到 F0 中，丢弃 F1 信息
fixup klmno F2: Add button functionality <-- 将 F2 的更改合并到 F0 中，丢弃 F2 信息
但更常见且推荐的方式是使用 reword 对最基础的提交进行修改，然后 squash 后面的提交，这样 Git 会自动创建一个包含所有被 squash 提交信息的草稿，方便你编辑最终的提交信息。

所以，使用 reword 和 squash 的组合：

reword abcde F0: Initial page structure
squash fghij F1: Add button (WIP)
squash klmno F2: Add button functionality

保存并关闭编辑器。

1. Git 会先暂停让你编辑 F0 的提交信息（因为用了 reword）。修改后保存关闭。
2. 然后 Git 会尝试将 F1 的更改应用并合并到 F0 中。如果没有冲突，它会继续。
3. 接着 Git 会尝试将 F2 的更改应用并合并到之前 F0+F1 合并后的提交中。

4. 完成 squash 后，Git 会打开一个新的编辑器，其中包含了 F0, F1, F2 的原始提交信息（如果是用 squash 而非 fixup）。你需要在这里编辑最终合并后的提交信息。例如，你可以写一个描述性的信息，概括这三个提交的总工作内容：

   “`
   Enhance page with interactive button

   Refactors page structure for easier component integration.
   Adds a functional button element.
   “`
   （注释掉的行不会包含在最终信息中）

保存并关闭编辑器。

Rebase 过程完成。现在你的 feature 分支历史看起来是这样的：

A---B---C---F (main)
\
F0' (feature) <-- 包含了 F0, F1, F2 的更改，有新的提交信息和 SHA-1

你成功地将三个提交合并成了一个干净的提交，并修改了信息。

3.3 其他交互式 Rebase 场景

• 修改单个提交信息 (reword)： 找到你想修改的提交行，将 pick 改为 reword，保存退出。Git 会暂停让你编辑该提交的信息。
• 删除提交 (drop)： 直接删除你想删除的提交所在的行，或者将 pick 改为 drop。保存退出。该提交将从历史中消失。
• 编辑提交 (edit)： 将 pick 改为 edit。Git 应用该提交后会暂停。你可以在此时进行任何修改（例如，修改文件内容，git add 添加到暂存区，然后 git commit --amend 修改当前提交），甚至可以 git reset HEAD^ 来撤销这个提交，然后将它的更改拆分成多个新的提交。完成后，使用 git rebase --continue 继续。
• 调整提交顺序： 直接在编辑器中复制粘贴行来改变提交的顺序。请注意，改变顺序可能会导致冲突，因为提交是基于其父提交的更改。

处理交互式 Rebase 中的冲突

与基本 Rebase 类似，交互式 Rebase 在应用任何一个提交时都可能遇到冲突。当 Git 暂停并报告冲突时，你需要：

1. 解决冲突文件。
2. git add <解决冲突的文件>。
3. git rebase --continue 继续。

如果你在某个 edit 步骤暂停时，做了修改并使用 git commit --amend 修改了当前提交，那么当你使用 git rebase --continue 时，Git 会直接应用 amend 后的提交并继续下一个步骤。

如果在任何时候想放弃整个交互式 Rebase 过程，可以使用 git rebase --abort。

4. Git Rebase 的风险：切勿变基已共享的历史！

这是使用 git rebase 最重要、最关键的注意事项。

永远不要对已经推送到共享远程仓库（比如 GitHub、GitLab、公司内部 Git 服务器等）的提交执行 git rebase。

原因：

1. Rebase 重写历史： 当你 Rebase 本地的提交并推送到远程后，这些提交拥有了新的 SHA-1 值，它们在 Git 眼中是全新的、与旧的提交不同的提交。
2. 公共历史分叉： 其他团队成员在你 Rebase 之前可能已经基于旧的提交（旧的 SHA-1）进行了开发。当他们从远程仓库拉取更新时，他们会看到远程仓库的历史与他们本地基于旧提交的历史是不兼容的。Git 无法简单地快进（Fast-forward）或者自动合并，因为它认为这是两条不同的历史线。
3. 强制推送与团队混乱： 要将你 Rebase 后的新历史推送到远程，你通常需要使用 git push --force 或 git push --force-with-lease。这将强制远程仓库接受你的历史，覆盖掉原有的历史。这会导致其他团队成员必须进行复杂的历史同步操作（例如，丢弃他们本地基于旧历史的更改，或者进行 Rebase Rebase 的操作），极大地增加了他们的工作难度和出错风险。

例外情况：

• 你确信自己是唯一一个在特定分支上工作的开发者，并且该分支没有被其他人使用或基于此创建新分支。 （这在个人项目中可以接受，但在团队项目中非常罕见且风险高）。

• 使用 git pull --rebase： 这是一个常见的用法，它实际上是在将远程分支的更改拉取到本地之前，先将你本地的、未推送的提交变基到远程分支的最新提交之上。

  “`bash

  等同于 git fetch 然后 git rebase origin/current-branch

  git pull –rebase
  “`
  这个操作只会修改你本地的、尚未共享的提交，因此是安全的。它能让你在拉取远程更新时保持本地分支的线性历史。

底线： 在 git push 到共享远程仓库之前，你可以自由地对你的本地分支进行 Rebase 和历史清理。一旦提交被推送，就不要再对它们进行 Rebase。此时如果需要集成更改，请使用 git merge。

5. 何时使用 Rebase，何时使用 Merge？

理解了 Rebase 的特性和风险后，我们可以总结一下 Rebase 和 Merge 的最佳使用场景：

使用 Git Rebase 的场景：

1. 清理本地特性分支历史（未推送前）： 这是 Rebase 最常见且推荐的用法。在你完成一个特性开发，准备将其合并到主分支（如 main 或 develop）之前，使用交互式 Rebase (git rebase -i) 来合并零碎提交、删除临时提交、修改提交信息，使你的特性分支提交历史清晰、简洁、有意义。
2. 将特性分支保持与目标分支同步： 在一个长时间运行的特性分支上工作时，为了避免与目标分支（如 main）产生过多冲突，你可以定期将特性分支变基到目标分支的最新提交上 (git rebase main)。这能让你在相对较小的步骤中解决与主分支的冲突，而不是等到最后一次性解决大量冲突。确保在执行此操作前，你的特性分支的更改尚未推送到共享远程。
3. 通过 git pull --rebase 拉取远程更新： 如果你偏好线性历史，并且习惯在拉取前确保本地没有要推送的提交，可以使用 git pull --rebase 代替 git pull。

使用 Git Merge 的场景：

1. 集成已共享的分支： 将一个已经完成开发并经过 review 的特性分支合并到主分支（如 main 或 develop）。这是标准的工作流程，Merge 操作会保留特性分支的历史，包括分支和合并的过程，这对于追踪特性开发路径和回溯历史非常有用。
2. 合并公共分支的更改： 当你需要将一个公共分支（如 main）的更改集成到另一个公共分支或已共享的分支时，使用 Merge。
3. 需要保留精确历史时： 如果项目的历史需要精确地反映出分支的创建、开发和合并过程，包括所有的中间提交，那么 Merge 是更好的选择。

总结：

• 本地私有工作： Rebase（尤其是 rebase -i）是清理历史的利器。
• 已共享工作： Merge 是安全集成的标准方式。
• 拉取更新： git pull --rebase 是保持本地线性历史的安全选项。

6. Rebase 的安全网：Git Reflog

尽管我们强调 Rebase 的风险，特别是对已共享历史的风险，但如果你不小心犯了错误（比如变基错了分支，或者在交互式 Rebase 中删除了不该删的提交），git reflog 是你的救命稻草。

git reflog（引用日志）记录了 HEAD 在本地仓库中移动的每一个位置。无论你进行了提交、切换分支、合并、变基，甚至重置（reset），reflog 都会记录下操作前 HEAD 所在的提交。

bash
git reflog

输出类似：

a1b2c3d (HEAD -> feature) HEAD@{0}: rebase finished: returning to refs/heads/feature
e4f5g6h HEAD@{1}: rebase: F2: Add button functionality
i7j8k9l HEAD@{2}: rebase: F1: Add button (WIP)
m0n1o2p HEAD@{3}: rebase: Initial page structure
q3r4s5t HEAD@{4}: checkout: moving from main to feature
u6v7w8x (main) HEAD@{5}: commit: Add new feature F
y9z0a1b HEAD@{6}: commit: F2: Add button functionality
c2d3e4f HEAD@{7}: commit: F1: Add button (WIP)
g5h6i7j HEAD@{8}: commit: Initial page structure
k8l9m0n HEAD@{9}: commit (initial): Initial project commit

每一行代表 HEAD 过去的位置。HEAD@{0} 是当前位置，HEAD@{1} 是上一个位置，以此类推。你可以看到之前执行的各种操作（rebase, checkout, commit）。

如果你发现 Rebase 搞砸了，你可以使用 git reset --hard HEAD@{N} 回到 Rebase 开始之前的状态。例如，在上面的 reflog 示例中，Rebase 是在 HEAD@{4} 之后开始的。要回到 Rebase 之前的 feature 分支状态，你可以执行：

bash
git reset --hard HEAD@{4}

或者，找到 Rebase 前 feature 分支的 SHA-1 (例如 y9z0a1b 或 c2d3e4f 或 g5h6i7j 之前的那个提交)，然后 git reset --hard <SHA-1>。reflog 提供了到达这些 SHA-1 的快捷方式 (HEAD@{N})。

git reflog 是一个强大的本地安全网，它能帮助你从很多 Git 操作失误中恢复，包括 Rebase 错误。熟练掌握 reflog 会让你在使用 Rebase 时更加自信。

7. 结论

Git Rebase 是一个功能强大的工具，它赋予了开发者重写和清理提交历史的能力。正确地使用 Rebase（主要是在本地、未共享的分支上）可以帮助你：

• 创建更干净、更易读的提交历史。
• 在将特性合并到主分支之前，优化提交粒度和信息。
• 保持本地分支与目标分支的同步，并在较小的冲突步骤中解决问题。

然而，Rebase 的核心在于“重写历史”，这使得它成为一个潜在的危险工具。核心原则是：永远不要对已经推送到共享远程仓库的提交执行 Rebase。 违背这个原则几乎肯定会导致团队协作上的混乱。

对于已经共享的提交，应使用 git merge 进行集成。

学习和掌握 Rebase 需要实践。建议你在一个测试仓库中反复练习基本 Rebase 和交互式 Rebase 的各种命令，熟悉其工作流程和潜在的冲突解决场景。同时，时刻记住 git reflog 这个安全网，它可以在你犯错时提供回滚的机会。

谨慎、有目标地使用 Rebase，它将成为你 Git 工具箱中不可或缺的一部分，帮助你和你的团队维护一个整洁、高效的代码仓库。

---