Split Big Changes into Reviewable Pieces Now That GitHub Stacked PRs Are Generally Available
This page contains Coupang Partners affiliate links; the operator may earn a commission.
Key Takeaway
Stacked PRs let you split a large change with dependent parts into small PRs and review them one at a time. GitHub made the feature generally available on October 6, 2026, and a stack can be merged together.
What kinds of changes are good to stack for review?
Take work that needs adding a data type, then server handling, then the screen update, in that order. You can split it so that each step depends on the one just below. This is an example made to explain the structure, not a result from any specific GitHub repository.
For reviewers, write the problem each PR solves and its dependencies above and below. If you split changes only by line count, the meaning of a layer gets blurry. The criterion for splitting is a responsibility you can explain on its own.
What changed with general availability?
| Feature | Scope in the October 6 official announcement |
|---|---|
| Approval retention | Approvals are kept when you rebase a stack whose content has not changed after the base branch moved ahead |
| Signing | GitHub creates signed replacement commits on rebase |
| Merge queue | Handles a stack as one merge group |
| Base branch deletion | Automatically adjusts the stack's target branch |
| CLI | Git worktree support in the gh stack extension |
Date checked 2026-10-10, source GitHub Changelog. Approval retention comes with the condition that the content is unchanged. Do not read it as meaning review is no longer needed even when you have edited the code.
Can I leave my merge settings as they are?
GitHub explains that stack merges are handled more consistently, and that with the merge commit method it creates one merge commit per PR. Try a small change first to check that the history shape your team expects matches the unit your CI runs on.
Auto-merge is planned to roll out over the weeks after the announcement date. Don't assume, from the words "general availability" alone, that auto-merge applies to every repository.
Can I use it in my GitHub environment?
The official announcement says it is available on all github.com plans. GitHub Enterprise Server is planned for a future release, so if you use a company server, first check whether your installed version supports it.
Adopt it first on a low-impact change. Check each layer's tests, protection rules, review status, and the overall behavior after the merge, and then widen the scope.
Frequently Asked Questions
Do I have to make every PR a stack?
No. It fits when you split dependent changes into small review units.
Are approvals kept if I change the code?
The official condition for keeping approvals is that the stack, after the base branch moved ahead and you rebased, has no other code changes. If you edited the code, that condition does not apply.
Does it work on Enterprise Server right away?
The October 6 announcement says it will be included in a future Enterprise Server release. Check whether your installed version supports it.
Sources & Verification Date
All materials have been verified from official announcements and may have changed since verification.