Stacked pull requests on GitHub: smaller reviews, one landing

Open a pull request with 1,500 changed lines and watch what happens to it. The reviewer reads the first few files with care, then the diff keeps going, the attention runs out, and the rest gets a scroll and an approval. Nobody is being lazy. A big diff asks for more focus than one sitting holds. On 6 October 2026 GitHub made stacked pull requests generally available, and they are its answer to exactly this: split one large change into a chain of small pull requests that are each reviewed on their own and still land together.

Why a big pull request gets a rubber stamp

As a general rule, a reviewer's attention drops as the diff grows. The first file gets real questions. By the fourteenth, the reviewer is checking that the code looks like code. The bug that matters is rarely in the file everyone expected to be risky; it sits in a small change to a shared helper, halfway down, where nobody was looking any more. The author pays too: a 1,500-line description is hard to write, so it usually says "see diff".

The obvious fix, smaller pull requests, has always had a cost. If the second piece depends on the first, you either wait for the first to merge before opening the second, or you open them as a chain and then maintain that chain by hand.

What a stack is, and what GA changed

A stack is a chain of branches where each one is based on the branch before it, and each branch has its own pull request. The first adds a migration, the second the service that uses the new column, the third the endpoint that calls the service. Each is reviewed independently, and the chain merges together.

The pain was never the idea. It was what happened when someone asked for a change in the first pull request after the second and third were already reviewed: every branch above had to be rebased by hand, and in repositories that dismiss stale approvals, the reviews above were thrown away too. GitHub's GA release goes straight at that. Its "Rebase stack" action keeps approvals for code that did not change, even in repositories that dismiss stale approvals. Rebased commits stay signed, because GitHub creates signed replacement commits and keeps the original author.

The rest of the release is about landing the stack. It enters and lands through the merge queue as a single merge group, and with the merge-commit method GitHub creates one merge commit per pull request. Bypass permissions apply to the lowest unmerged pull request in the stack. If a stack branches and its base branch is deleted, the pull requests above retarget automatically instead of the bottom one being closed. Auto-merge for stacks, where every pull request in a selected group merges once all of them are ready, is rolling out over the following weeks. For moving around, the stack shows in the pull request header, Shift+J and Shift+K step between its pull requests, the timeline records when one is added or removed, the pull_request webhook gains a stacked action, and the gh stack extension for GitHub CLI works with Git worktrees.

GitHub also published numbers from the preview period: it says repositories using stacks merged 9% more code than their peers, and that over two-thirds of the top 1% of repositories now use stacks and saw a 5% improvement in time-to-merge. Read those as GitHub's measurements of its own feature, not as an independent study.

If you are the only reviewer

A lot of freelance and solo work has no second reviewer. The stack still earns its keep, for reasons that are general and have nothing to do with GitHub's figures. Reviewing your own 200-line diff the next morning catches things that reviewing your own 1,500-line diff never will. A client can be shown step two working before step three exists. When something breaks a month later, git bisect lands on a small, named change instead of one giant commit. And if the client's own developer takes the project over, they inherit a history they can actually read.

When not to stack

A stack is overhead, so it should buy something. Skip it when the change is already small enough to review in one go. Skip it when the pieces cannot be judged apart: if the first pull request only makes sense after reading the third, it is one change, and splitting it just spreads the confusion over three tabs. Be careful when the bottom of the stack is still moving a lot, because every change there ripples upward, and even with approvals kept, reviewers above are reading against a moving base. And a stack waits on its lowest pull request, so on a team where reviews take days, a five-deep stack can sit longer than one honest medium-sized pull request would.

The next time a branch passes a few hundred lines, stop before opening the pull request and write down the steps it actually took. Each step that a reviewer could approve alone is a pull request in the stack; the rest belong together. Source: GitHub changelog, "Stacked pull requests generally available" (6 October 2026).