Git Rebase 初学者指南：简单入门

Sep 21, 2025 · 2 min read

简介

如果你曾经查看过自己的 Git 历史记录并想”这简直是一团糟”，那你并不孤单。那些纠缠不清的分支线和冗余的合并提交让人很难理解实际发生了什么变化以及何时发生的。这就是 git rebase 发挥作用的地方——一个强大的工具，帮助你维护干净、可读的提交历史。

在本指南中，你将学习变基的作用、它与合并的区别，以及何时在日常工作流程中使用它。我们将专注于你今天就可以开始使用的实际示例，同时强调需要避免的关键陷阱。

核心要点

Git rebase 将提交重放到另一个分支之上，创建线性历史
使用 rebase 保持功能分支的最新状态并在分享前清理提交
永远不要对其他人正在使用的分支进行变基
交互式变基允许你压缩、重新排序和编辑提交
变基后使用 --force-with-lease 安全地强制推送

什么是 Git Rebase？

可以把 git rebase 想象成重写历史——但是是以一种好的方式。当你进行变基时，你是在将一个分支的提交拿到另一个分支上重放，就好像你从不同的起点开始工作一样。

想象你在写一个故事。你开始写第3章，而你的同事还在编辑第2章。当他们完成时，你可以：

合并：添加一个注释说”在这里插入了同事的第2章更改”
变基：重写你的第3章，就好像你在第2章已经完成后才开始写的

变基方法为你提供了一个更干净的叙述，没有”合并噪音”。

为什么使用 Git Rebase？

保持历史线性和干净

线性历史读起来就像一本书——一个提交接着另一个提交，形成清晰的序列。这使得以下操作更容易：

追踪错误是何时引入的
理解功能的演进过程
在拉取请求中审查代码更改

没有变基，你的历史会充满重复说着”Merged branch ‘main’ into feature-xyz”的合并提交，掩盖了实际完成的工作。

开发者选择 Rebase 的时机

开发者在两种主要情况下会使用变基：

保持最新状态：你的功能分支需要来自 main 分支的最新更新
完善工作：你希望在其他人审查之前清理提交

这两种场景都有助于维护那种让每个人的生活都更轻松的干净线性历史。

Git Rebase vs Merge：关键区别

这里是根本区别：

Merge 创建一个新的提交来合并两个分支：

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

Rebase 将你的提交重放到目标分支之上：

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

注意变基如何创建新提交（D’ 和 E’），而合并添加了一个合并提交（M）。变基的结果是线性和干净的，而合并保留了确切的历史但增加了复杂性。

Git Rebase 的常见用例

更新你的功能分支

你正在开发一个功能，而你的团队向 main 分支推送更新。要合并他们的更改：

git checkout your-feature-branch
git rebase main

这会将你的提交重放到最新的 main 分支之上，保持你的分支最新，而不会产生合并提交。

在拉取请求前清理提交

在分享你的工作之前，你可能想要整理你的提交。交互式变基让你可以：

git rebase -i HEAD~3

这会打开一个编辑器，你可以在其中：

将多个”进行中的工作”提交压缩为一个
重新排序提交以获得逻辑流程
编辑提交消息以提高清晰度

例如，将这个：

- Fix typo
- WIP: add login
- More login stuff
- Fix tests

转换为这个：

- Add user login functionality with tests

重要警告：何时不要使用 Rebase

黄金法则：不要对共享分支进行变基

永远不要对其他人正在使用的分支进行变基。当你进行变基时，你正在创建具有不同 SHA-1 哈希值的新提交。如果其他人拥有旧提交，Git 会感到困惑并创建重复提交。

可以安全变基的：你的本地功能分支
永远不要变基的：main、develop 或任何其他人使用的分支

理解强制推送的风险

变基后，你通常需要强制推送：

git push --force-with-lease origin your-feature-branch

--force-with-lease 标志比 --force 更安全，因为它会检查自你上次拉取以来是否有其他人推送了更改。尽管如此，只对你拥有的分支进行强制推送。

Git Rebase 入门

这里是一个简单的练习工作流程：

从 main 分支创建一个功能分支
进行一些提交
与此同时，main 分支得到更新

对你的功能分支进行变基：

git checkout feature-branch
git rebase main

如果发生冲突，解决它们并继续：
```
git add .
git rebase --continue
```

从你的本地分支开始练习，在对任何共享内容进行变基之前建立信心。

结论

Git rebase 是维护干净、线性提交历史的强大工具。通过重放提交而不是合并，你创建了一个更可读的项目历史，这对你的整个团队都有益。记住黄金法则——只对你尚未推送或其他人未使用的分支进行变基——你就能避免常见的陷阱。

今天就开始用你的功能分支练习吧。一旦你体验到线性历史的清晰性，你会想知道没有它你是怎么工作的。

常见问题

是的，你可以使用 git reflog 找到变基前的提交哈希，然后使用 git reset --hard 返回到那个状态。Git 保留了 HEAD 指向位置的本地历史，所以你可以从大多数错误中恢复。

Git pull 执行获取后跟合并，创建一个合并提交。Git pull --rebase 执行获取后跟变基，将你的本地提交重放到远程分支之上，获得更干净的历史。

不，两者都有各自的用途。使用 rebase 进行本地清理和保持功能分支最新。使用 merge 将完成的功能合并到主分支中，在那里保留完整历史很重要。

运行 git rebase --abort 来停止变基并将你的分支返回到变基开始前的原始状态。这在你正在解决冲突或在交互式变基的任何时候都有效。

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.