When GitHub Stacked PRs Keep Approvals After a Rebase

An updated base does not always require another review

Your team has approved a stack, but main advances before it lands. GitHub’s October 6 general availability release lets Rebase stack preserve approvals when the stack’s code remains unchanged, including repositories that dismiss stale approvals.

The condition is the unchanged diff. A rebase that also modifies the feature or changes code while resolving a conflict does not automatically qualify. New commit identities and new reviewable changes are different things; the feature avoids repeating review of unchanged code.

Keep dependencies while giving each change its own review

A stacked pull request targets the branch below it. The bottom PR targets the trunk, often main. Reviewers see the incremental change in each layer rather than having to review the entire feature in one diff.

For example, a feature could separate shared types, an API using those types and a screen consuming that API:

This is a possible decomposition, not a prescribed architecture. It lets the next change proceed before its dependency merges. After the bottom PR lands, GitHub automatically rebases the remaining branches.

Retained approval is only one part of being ready to merge

The stack reference requires the selected PR and every lower PR to satisfy the stack base’s protections. The history between branches must also be linear. An approval on PR 3 does not let it bypass a failing check on PR 2.

Reviews, required checks and CODEOWNERS are evaluated against the stack base, not merely the branch immediately below each PR. A GitHub Actions workflow configured for pull_request events targeting main runs for every layer of a stack based on main.

Review policies need a separate look. Branch protection settings distinguish dismissing approvals after the reviewed diff changes from requiring someone other than the last pusher to approve the most recent reviewable push. Read the unmet requirement in the merge box rather than using an approval badge as the entire diagnosis.

Rebase the stack, then inspect the remaining requirements

Use Rebase stack on GitHub or the gh stack CLI extension. In the local extension workflow, run gh stack rebase, then gh stack push. The GA update also added signed replacement commits for the server-side stack rebase.

A useful review sequence is to check whether the diff changed, whether lower layers have failed checks or missing reviews, and whether a separate latest-push approval requirement remains. Keeping those questions separate avoids weakening a review policy simply to remove a blocked merge.

Frequently asked questions