Updating Stacked Pull Requests with git rebase --onto

# Updating Stacked Pull Requests with git rebase --onto Source: [https://bd103.dev/blog/2026-06-18-git-rebase-onto/](https://bd103.dev/blog/2026-06-18-git-rebase-onto/) 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: ``` # Make sure we're on the second PR's branch. git switch second-pr # Tell commit C that its new parent is E, not B. 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`](https://git-scm.com/docs/git-push#Documentation/git-push.txt---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](https://stackoverflow.com/a/39081674)that inspired this article\!*