操作指南: Git Rebase 的正确用法
rebase 的核心是保持提交历史的整洁。
1. 定义
git rebase,变基。
本质是把你分支上的一系列提交,在另一个基底上(通常是主分支的最新 commit)重放一遍。目标是让你的分支历史看起来像是直接从主分支最新点开发出来的。
-
变基前:
A---B---C (feature 分支) / D---E---F---G (main 分支) -
变基后:
A'--B'--C' (feature 分支) / D---E---F---G (main 分支)A、B、C 的内容没变,但它们的 commit ID 变了,成了 A’、B’、C’。
2. 对比 Merge
| 特性 | rebase | merge |
|---|---|---|
| 历史线 | 线性、干净 | 非线性,保留分叉记录 |
| 提交记录 | 重写历史(ID变化) | 新增一个合并提交 |
| 优点 | 历史清晰,易于追溯 | 真实记录所有开发轨迹 |
| 缺点 | 破坏了原始提交记录 | 合并提交过多,历史杂乱 |
选择哪个,是团队规范问题,不是技术优劣问题。
3. 使用原则
-
黄金法则:永远不要对公共分支(如
main,develop)执行rebase。-
任何已经推送到远程,并且可能有他人拉取了的分支,都算公共分支。
-
重写公共历史会给所有协作者带来混乱。
-
-
适用场景:
-
同步主干更新:在个人开发分支上,定期 rebase 主分支,获取最新代码,避免将来巨大的合并冲突。
-
整理提交历史:在提交 Pull Request (PR) 之前,使用交互式 rebase 清理自己的 commit 记录。
-
4. 基本操作
命令
# 切换到你的特性分支git switch feature
# 拉取主干最新代码 (非必须,但推荐)git fetch origin main
# 将 feature 分支变基到最新的 main 分支上git rebase origin/main冲突解决
-
rebase过程因冲突暂停。 -
手动解决文件中的冲突。
-
执行
git add <解决冲突的文件>。 -
执行
git rebase --continue继续重放下一个提交。
如果过程复杂或出错,用 git rebase --abort 可以随时撤销,回到 rebase 开始前的状态。
5. 交互式 Rebase (-i)
这是 rebase 最强大的功能。用于在推送前整理本地提交。
命令
# 整理最近的 3 个提交git rebase -i HEAD~3执行后,会进入一个文本编辑器,列出你的提交:
pick 1a2b3c4 feat: add feature Apick 5d6e7f8 fix: fix bug in Apick 9g8h9i0 chore: typo常用指令
-
p,pick:保留该提交(默认)。 -
r,reword:保留该提交,但修改提交信息。 -
s,squash:将该提交合并到上一个提交中,并合并提交信息。 -
f,fixup:同squash,但丢弃该提交的提交信息。 -
d,drop:删除该提交。
例如,将后两个提交合并到第一个:
pick 1a2b3c4 feat: add feature As 5d6e7f8 fix: fix bug in Af 9g8h9i0 chore: typo保存退出后,3 个提交会变成 1 个,历史记录非常干净。
6. 风险与补救
-
风险:
rebase会重写历史,如果操作不当,可能丢失提交。 -
补救措施:
git reflog。-
该命令记录了你本地仓库所有 HEAD 的移动历史。
-
如果
rebase搞砸了,可以通过reflog找到rebase之前的 commit ID。 -
使用
git reset --hard <commit_id>即可恢复到指定状态。
-
reflog 是你的安全网。