Git Rebase 从入门到精通：让提交历史干净如新
一句话先说透（请刻进 Git 肌肉记忆）：
git rebase 就是把你本地的“新活儿”（提交）先拿下来，等别人最新的活儿干完后，再把你的活儿重做一遍，假装你一开始就是在最新基础上干的。
无论你是用 -i 整理提交，还是用 --onto 精准搬家，甚至用 --rebase-merges 保留复杂拓扑——这句话都成立。
一、Rebase 的本质：重放，不是合并
Rebase 不会创建“合并提交”，而是：
- 找出当前分支相对于目标分支的独有提交序列；
- 将这些提交视为一系列 patch（变更集）；
- 把分支头移动到目标分支最新处；
- 逐个重新应用这些 patch（底层机制类似
cherry-pick）。
结果：一条干净、线性的提交历史（默认情况下）。
⚠️ 注意：每个重放的提交都是新对象（SHA-1 不同），因为父提交变了。
二、交互式 Rebase（-i / --interactive）——提交整理神器
这是最常用也最强大的功能，用于压缩、重排、修改或拆分提交。
git rebase -i main # 整理当前分支相对于 main 的提交
git rebase -i HEAD~5 # 整理最近 5 个提交进入编辑器后，每行代表一个提交，可使用以下指令：
| 指令 | 作用 |
|---|---|
pick |
保留该提交（默认） |
reword |
保留提交，但修改提交信息 |
edit |
在此提交处暂停，允许修改代码、拆分或添加文件 |
squash |
合并到上一个提交，并编辑合并后的信息 |
fixup |
合并到上一个提交，丢弃本提交信息（适合小修复） |
drop 或删除整行 |
完全丢弃该提交 |
实用技巧：
自动整理 fixup 提交：
git commit --fixup abc123 git rebase --autosquash -i mainGit 会自动将
fixup! abc123的提交排序到abc123后并标记为fixup。在 rebase 中运行测试：
git rebase -i -x "npm test" main每重放一个提交，就自动执行一次测试，确保历史始终可运行。
三、高级参数详解（补齐所有关键选项）
1. --rebase-merges（保留分支拓扑！）
普通 rebase 会把带 merge 的历史“压平”成线性，丢失开发流程结构。--rebase-merges 则会重建 merge commit，保留原始分支合并关系。
git rebase --rebase-merges main✅ 适用场景：
- 团队使用 feature 分支 + merge workflow
- 需要 rebase 到新基底，但不想丢失“谁在什么时候合并了什么”的语义
需 Git 2.22+。交互模式下会看到
merge -C <commit>指令。
2. --keep-empty
默认 rebase 会跳过空提交（无文件变更的提交）。
但有时空提交有意义（如触发 CI、占位、文档标记）。
git rebase --keep-empty main→ 强制保留这些“看似无用”但实际有用的提交。
3. --root
重写整个项目历史起点，从第一个提交开始变基。
git rebase --root -i # 交互式重写全部历史常见用途：
- 剥离子项目（配合
git filter-repo更安全） - 重写初始提交（如修正作者信息）
- 清理早期敏感数据（⚠️ 极其危险，仅限未共享仓库）
4. --update-refs（Git 2.38+）
当你 rebase 的提交段被多个本地分支或标签引用时，普通 rebase 只更新当前分支，其他引用仍指向旧提交，导致“悬空”。
--update-refs 会自动更新所有指向被 rebase 提交的本地引用！
git rebase --update-refs -i main✅ 极大提升多分支协作下的 rebase 安全性，避免手动同步多个分支。
5. 其他实用参数
| 参数 | 说明 |
|---|---|
--committer-date-is-author-date |
让 committer 时间 = author 时间，避免时间倒挂 |
--ignore-whitespace |
忽略空白差异，减少无关冲突 |
-x <cmd> / --exec <cmd> |
在每个提交后执行命令（如自动测试） |
四、rebase --onto vs cherry-pick：真正区别在哪？
很多人说“rebase 保证顺序，cherry-pick 不保证”——这是错的。
✅
git cherry-pick A B C会严格按 A → B → C 的顺序应用提交。
那区别到底在哪？
核心差异：上下文感知 vs 盲目复制
| 维度 | git cherry-pick |
git rebase --onto |
|---|---|---|
| 操作单位 | 单个或多个 commit ID | 一个连续提交区间（<oldbase>.. <branch>） |
| 是否理解历史结构 | ❌ 只看 diff，不关心这些提交如何产生 | ✅ 知道这是从 <oldbase> 开始的一段完整开发 |
| 依赖完整性 | 需用户手动确保依赖提交存在 | 自动基于共同祖先迁移，天然保持内部一致性 |
| 语义意图 | “我要这个改动的结果” | “我要把这段开发过程搬过去” |
举个典型场景：
历史：
A — B — C (main)
\
D — E — F (feature)D: 创建utils.jsE: 在login.js中调用utils.jsF: 修复utils.js的 bug
你想把 E 和 F 移到 main。
❌ 用 cherry-pick E F：
E的变更包含对utils.js的调用，但main上根本没有这个文件！- → 要么冲突，要么 apply 成功但代码运行时报错（逻辑断裂）
✅ 用 rebase --onto main D feature：
- Git 理解你要迁移的是
D之后的所有提交（即E, F） - 虽然
D本身不被包含，但如果你发现E依赖D，你会意识到：应该从C开始搬，包含D - 即便冲突，也是正确的冲突——提醒你缺失依赖
💡 关键洞察：
rebase --onto强制你思考“迁移的起点”，而cherry-pick容易让你忽略上下文依赖。
总结：
- 用
cherry-pick：当你明确知道某个提交独立可用（如热修复、跨版本补丁）。 - 用
rebase --onto：当你想迁移一段连贯的开发历史，并希望 Git 帮你保持逻辑完整性。
五、完整命令速查表
| 命令 | 作用 | 适用场景 |
|---|---|---|
git rebase <branch> |
基础变基 | 同步主干，线性历史 |
git rebase -i <branch> |
交互式整理提交 | PR 前清理、合并 WIP |
git rebase --continue |
冲突解决后继续 | rebase 中断恢复 |
git rebase --abort |
放弃并回退 | 操作失误回滚 |
git rebase --skip |
跳过当前提交 | 极端情况丢弃冲突提交 |
git rebase --onto <new> <old> <branch> |
精准迁移提交段 | 修复分支起点、提取功能 |
git rebase --rebase-merges <branch> |
保留合并拓扑 | 复杂分支历史迁移 |
git rebase --keep-empty <branch> |
保留空提交 | 保留 CI 触发/占位提交 |
git rebase --root [-i] |
重写整个历史起点 | 项目初始化、历史剥离 |
git rebase --update-refs [-i] <branch> |
自动更新相关引用 | 多分支/标签协同 rebase |
git rebase -x "cmd" <branch> |
每步后执行命令 | 自动化测试、验证 |
git rebase --autosquash -i <branch> |
自动整理 fixup!/squash! |
配合 --fixup 使用 |
📌
--onto参数口诀：
“把<branch>上从<old>之后的提交，搬到<new>后面”
六、黄金原则：何时能用？何时禁用？
✅ 安全使用：
- 本地私有分支（未 push）
- 尚未共享的提交
- PR 合并前整理（团队允许 force push）
❌ 绝对禁止：
- 已推送到共享远程的分支（如
main、develop、多人 feature） - 公共历史（除非全员协调 + 强制同步）
💡 最佳实践：
git branch backup-$(date +%m%d) # 操作前备份！
七、结语：Rebase 是可控的历史重写艺术
rebase = 拿下你的活 → 等别人干完 → 在最新基础上重做一遍。
从简单的同步，到保留 merge 的复杂拓扑，再到自动更新多分支引用，
现代 Git 让 rebase 越来越强大、安全、智能。
掌握它，你不仅能写出教科书级的提交历史，还能在复杂协作中游刃有余。
版权所有 © 【代码谷】 欢迎非商用转载，转载请按下面格式注明出处，商业转载请联系授权，违者必究。（提示：点击下方内容复制出处）
源文： Git Rebase 从入门到精通：让提交历史干净如新 ，链接：https://www.daimagu.com/article/2512171215303781.html，来源：代码谷
评论