Retarget a stacked PR before you delete its base

You split a change into two pull requests. The second one builds on the first, so it targets the first one's branch instead of main. That's called a stacked pull request. Now the first one is reviewed, and you merge it.

I merged the first pull request with the GitHub CLI and its option to delete the branch afterwards:

gh pr merge <first> --merge --delete-branch

The merge worked. But the second pull request was closed. Its base branch no longer existed, so it had nothing left to target.

Getting it back

I pushed the deleted branch again, reopened the second pull request and changed its base to main. The code was all still there.

Then the next surprise: no checks ran. My CI only starts for pull requests that target main, and changing the base didn't start a new run. The workflow runs on the opened, synchronize and reopened events, and changing the base is only an edit. Closing the pull request and opening it again did.

The safe order

Your second pull request is a ladder leaning on the first. Before you take the first away, lean the second against the wall. The wall is main. The analogy stops at the damage: a fallen ladder stays fallen, but a closed pull request can be reopened.

So retarget first, then merge and delete:

gh pr edit <second> --base main
gh pr merge <first> --merge --delete-branch

The first line points the second pull request at main, so deleting the old branch leaves it untouched.

GitHub normally does this for you: when you delete the branch of a merged pull request, it moves the pull requests stacked on it to main. That didn't happen here, and a GitHub CLI issue (opens in a new tab) reports the same with --delete-branch. Retargeting first is a cheap safeguard.

Try it: before you merge a pull request with a branch delete, list the pull requests that target its branch with gh pr list --base <branch>.