git rebase --onto 的正确参数顺序是 git rebase --onto ，即“把 中从 开始的提交搬至 后”，顺序颠倒会导致分支错乱或丢 commit。
git rebase --onto 用错参数顺序就白忙活
很多人执行 git rebase --onto 后发现分支没动、提交乱了，甚至丢掉 commit——根本原因是把「目标基点」和「旧基点」位置搞反了。它不是“把 A 改成基于 B”，而是“把 A 中从 C 开始的提交，搬到 B 后面去”。
典型错误写法：git rebase --onto main feature bugfix（误以为是“把 bugfix 嫁接到 main 上”）
正确逻辑是：git rebase --onto <newbase><oldbase><top></top></oldbase></newbase>，三个参数缺一不可，且顺序不能换。
-
<newbase></newbase>：你想让那一段提交“落地”的新起点（比如main） -
<oldbase></oldbase>：你要“切下来”的那段提交的起始分界（通常是旧分支的起点，比如feature） -
<top></top>：你要搬运的提交范围的终点（通常是当前分支名，比如bugfix）
示例：要把 bugfix 分支中“从 feature 分出去之后”的所有提交，重放到 main 顶端：git rebase --onto main feature bugfix
rebase --onto 前必须确认提交范围是否干净
这个命令不会帮你判断哪些 commit 该搬、哪些不该搬——它只按 <oldbase></oldbase> 到 <top></top> 的拓扑关系机械提取。如果 bugfix 曾经 merge 过 main，或者 feature 本身有 rebased 历史，git merge-base feature bugfix 可能算不准起点，导致漏提或重复提。
- 先运行
git log --oneline --graph feature...bugfix看实际差异范围 - 用
git merge-base feature bugfix检查默认分叉点，再对比日志手动确认<oldbase></oldbase>是否合理 - 如果
bugfix是从feature的某个特定 commit 分出的，直接用那个 hash 替代feature更稳妥
常见现象：执行后发现少了几个 fix 提交——大概率是 <oldbase></oldbase> 设得太靠前，把本该保留的共同祖先也排除进去了。
交互式 rebase + --onto 容易触发冲突但不可跳过
一旦涉及修改历史，--onto 必然重放每个 commit。哪怕只是移动几个提交，只要它们改动的文件在 <newbase></newbase> 上已被修改过，就会停在冲突处。这不是 bug，是设计使然。
- 冲突时别直接
git rebase --skip，那会丢掉整个 commit - 解决完记得
git add再git rebase --continue，否则下个 commit 还会卡住 - 如果中途想放弃，用
git rebase --abort，它会恢复到 rebase 前状态（前提是没强制 push 过）
注意：git status 在 rebase 过程中显示的是“REBASING”，不是 “ON BRANCH”，别误以为还在原分支上操作。
push 强制覆盖前得看团队协作约束
rebase --onto 改写了本地 commit hash，要同步到远程必须 git push --force-with-lease。但这不是技术问题，是协作问题。
- 如果
bugfix已被别人基于开发，你 force push 会导致他们后续 merge 出现重复提交或断链 - GitHub/GitLab 上的 PR 会自动关闭或失联，因为源分支的 commit ID 全变了
- CI/CD 流水线可能缓存了旧 commit，重放后测试记录对不上
真正容易被忽略的一点：即使你一个人用，只要分支曾被 git push 过，就得当心本地 reflog 和 remote tracking branch 的状态不一致。建议做完 rebase --onto 后立刻跑 git log --oneline origin/bugfix..bugfix 确认差了多少 commit，再决定要不要 force push。
