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 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!