mainM1M2
- A
a1f3022挂在 M1 - B
b2e7d51挂在 M1
分叉未重放
main 已到 M2。A/B 还接在旧 M1 上，PR 会显得落后。
版本协作 · 版本协作
变基Rebase
把一串提交摘下来、逐个接到新基底上重放，得到一条直线历史；它改写提交哈希，所以只重写自己独有的历史。
先认出还挂在旧基底上的车厢，再接到新的 main
下面就是 rebase 时那条轨道。默认 A/B 还接在旧 M1；冲突会把失败写在 B 车厢上；解决后才会出现带新哈希的 A′/B′。
第 0 步先打开：终端跑 git fetch 再 git rebase origin/main。下面就是那条要重接的轨道。
原因：feature 从旧 M1 分叉。下一步：开始 rebase，或先看冲突会怎样卡住。
知识点：摘下来重放，哈希会变
车厢刚走过的路，这里只给命名。
- rebase 把一串提交从旧基底摘下，逐个接到新基底上。
- 每个重放都会生成新对象，所以 sha 会变。
- 冲突按提交逐个解决，不是一次混在一起。
- 只重写自己独有的历史；已被队友拉走的分支改用 merge。
什么时候用、怎么用
rebase 整理自己的线，不改写别人的线。
- 信号：私有 feature 落后 main，想让 PR 变成一条直线。
- 最短路径：
git fetch→git rebase origin/main→ 冲突就 add 再--continue→ 私有分支才--force-with-lease。 - 不适用：共享分支、已发布历史、拿不准就
git rebase --abort。
正反例：同一条 feature，推送方式不同
只改「有没有人在用这条分支」，结果完全不一样。
只有自己在写。历史是直线，PR diff 干净，lease 发现远端有新提交会停下。
队友已基于旧 sha 开发。强推后他们的 origin 断裂，冲突反复出现。
快速自测
队友已经在用的 feature 落后 main 了。想跟上又不让队友的 origin 断裂，哪种做法对？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。