rebase 能让历史更线性，但它不是把原来的提交原封不动搬过去。
本文使用Git 2.x 与独立演示仓库。Git（分布式版本管理）保存提交对象和引用，工作区、暂存区与提交历史不是同一份状态。每次操作先判断它改变哪个区域，再决定是否适合当前协作情境。
1. 从现象推到机制
提交标识由内容、父提交和元信息等共同决定。改变父提交后会生成新的提交，即使补丁看起来相同也不再是同一个对象。共享分支上改写历史，会让其他人的后续工作继续基于旧身份。
图中的四个节点分别表示旧开发线、新基础、重放补丁、协作检查。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
只在个人临时分支演示，把本地变化重新应用到更新后的基础。完成后对比文件内容和提交图，理解内容相似与历史身份不同。
1
2
3
4
git log --graph --oneline --all
# 仅在未共享的演示分支中研究
git rebase demo-base
git log --graph --oneline --all
示例在没有私人资料的临时仓库执行。先看 status、diff 与 log，再运行改变状态的命令；共享历史优先新增提交表达修复，不用改写历史掩盖已经发生的变化。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 父提交发生改变 | 重新生成的提交号会变化 |
| 补丁内容完全相同 | 不代表提交对象相同 |
| 其他人已基于旧分支开发 | 改写会增加集成成本 |
对照 1：父提交发生改变
重新生成的提交号会变化。观察时记录新旧父链与对象身份。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：补丁内容完全相同
不代表提交对象相同。观察时记录提交元信息和父节点。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：其他人已基于旧分支开发
改写会增加集成成本。观察时记录远端协作与分叉历史。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
是否使用 rebase 取决于团队约定。已经公开共享的修复通常可以用普通合并或新增提交表达，无需为了日志美观重写共同历史。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“其他人已基于旧分支开发”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
