Updating Stacked Pull Requests with git rebase --onto
摘要
文章分享作者遇到的场景：多个依赖的 Pull Request 中，Reviewer 将提交 B squash 成新提交 E，导致后续提交 C 的父节点仍指向旧的 B；作者给出 git rebase --onto <newparent> <oldparent> 命令来更新父节点（例如 rebase C onto E starting at B），说明这是更新 stacked PR 专用；并指出仅添加新提交的 PR 无需此命令，可用普通 git rebase；最后推荐 git push --force-with-lease 安全推送远程变更。
荐读理由
git rebase --onto <newparent> <oldparent> 命令能让被 reviewer 强制 squash 的 commit 的子 commit 正确指向新父 commit，完美解决叠堆 PR 拆分导致的关联混乱，照此就能直接应用到你的下一个 stacked pull request 上
原文
Updating Stacked Pull Requests with git rebase --onto
2026-06-18
Sometimes I find myself in the situation where I have multiple pull requests that build off of each other.
Then, a reviewer asks me to squash commit B into commit A, creating a new commit E. I do so, but now my second pull request is all messed up!
When Git created commit E, it didn't tell commit B's children that their new parent should be commit E. This means that commit C still thinks its parent is commit B!
While this behavior is a sensible default, in this scenario we don't want it. We can tell commit C that its new parent is commit E by rebasing it with the following command:
git switch second-pr
git rebase --onto E B
The general form of this command is git rebase --onto <newparent> <oldparent>, and it's very useful when updating stacked pull requests where the parent commit has been replaced. You don't need it if the base pull request only had new commits added, though, in which case you would use a normal git rebase without the --onto option. Once you do rebase your second pull request, take a look at the --force-with-lease option of git push to safely push your changes to the remote.
Thank you to sEver on Stack Overflow for the answer that inspired this article!
这条对你有帮助吗？