Git Internals
rebase 内部机制与 sequencer
从 sequencer 视角理解 rebase 的提交重放过程，帮助定位 rebase 中断、冲突恢复与历史重写后的提交变化。
- 想建立稳定 Git 心智模型的学习者
- 经常遇到历史、引用、恢复问题的开发者
- 会看基础命令输出
- 知道提交、分支、HEAD 这些名词
- 只背底层术语却不连接到实际命令
- 把对象、引用、工作区混成一层理解
数据 / 性能事实
- replayeach replayed commit gets a new SHA because its parent changed — history is rewritten, not moved出处: git-rebase(1) official manual
关键引语
Rebase works by replaying each commit from the branch being rebased onto the new base, producing new commits with different hashes but the same changes.
引用与延伸阅读
- Git rebase [官方]
- Git cherry pick [官方]
- Git reflog [官方]
学完这篇你会掌握什么
- 理解 rebase 内部机制与 sequencer 的核心作用和适用场景
- 掌握 rebase 内部机制与 sequencer 的基本用法和常用参数
- 从 sequencer 视角理解 rebase 的提交重放过程，帮助定位 rebase 中断、冲突恢复与历史重写后的提交变化。
- 理解 它在做什么 相关的概念
- 掌握 为什么提交 ID 会变化 相关的操作
- 知道在什么场景下使用该命令，什么场景下避免使用
rebase 本质上是“按顺序重放提交”，而 sequencer 是管理这条重放队列的执行器。
先想一个问题
你每天都在用 Git 命令，但偶尔会遇到一些 '奇怪' 的行为——比如明明没改文件却被提示有改动，或者 rebase 时突然多了预期之外的冲突。你想理解 Git 底层是怎么工作的。
它在做什么
- 计算待重放提交集合
- 按顺序把提交应用到新 base
- 遇冲突暂停，等待用户处理
- 继续直到队列结束
rebase 前
main
ABCD
feature
BEF
rebase 后
main
ABCD
feature
DE'F'
为什么提交 ID 会变化
因为 rebase 生成的是新提交对象，父指针和对象内容都可能变化。
--continue / --skip / --abort 的本质
continue：继续执行队列skip：跳过当前提交abort：丢弃队列执行结果，回到起点
出错恢复思路
先保住位置，再决定是否重来：
git reflog
git switch -c rescue/pre-rebase HEAD@{n}
连续跳过容易无意丢失关键补丁。每次 skip 前都应明确“这个提交为什么可跳过”。
接下来建议继续看什么
给你的练习
- 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
- 尝试该命令的不同参数选项，对比输出结果的差异
- 模拟一个需要使用该命令的实际场景，完整走一遍操作流程
延伸阅读
沿着同一主题继续深入：