Git Internals
rebase 内部机制与 sequencer
从 sequencer 视角理解 rebase 的提交重放过程，帮助定位 rebase 中断、冲突恢复与历史重写后的提交变化。
- 想建立稳定 Git 心智模型的学习者
- 经常遇到历史、引用、恢复问题的开发者
- 会看基础命令输出
- 知道提交、分支、HEAD 这些名词
- 只背底层术语却不连接到实际命令
- 把对象、引用、工作区混成一层理解
rebase 本质上是“按顺序重放提交”，而 sequencer 是管理这条重放队列的执行器。
它在做什么
- 计算待重放提交集合
- 按顺序把提交应用到新 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 前都应明确“这个提交为什么可跳过”。
接下来建议继续看什么
recover after rebasecommit graphgit-rebase