GitHub Stacked PRs Go GA: A Standard Answer for AI-Era Giant Diffs

What happened

On October 6, GitHub announced that stacked pull requests are generally available. The pitch in one line: break a large change into smaller, focused pull requests that you can review independently and merge together.

The numbers GitHub attached are worth a look: since public preview, repositories using stacks have seen 9% more merged code than peers; among the top 1% of repositories, over two-thirds now use stacked PRs and have seen 5% faster time-to-merge. That's GitHub's own reporting — sample and methodology undisclosed — but the direction matches lived experience: small steps merge more easily than giant PRs.

What GA adds

This isn't just removing the beta label; it fixes a batch of real review-experience pain points:

Approvals survive rebases. When the base branch (say, main) moves ahead and the stack needs rebasing, Rebase stack now preserves approvals — even in repositories that dismiss stale approvals. This was previously the biggest dealbreaker: hard-won approvals wiped out by one rebase.

Rebased commits stay signed. GitHub creates signed replacement commits during Rebase stack, preserving original authorship; automatic rebases after partial merges do the same when branch rules require signatures or the original commits were signed.

Merging behaves as one unit. A stack now enters and lands through the merge queue as a single merge group; with the merge-commit method, GitHub creates one merge commit per pull request instead of one for the whole group. That keeps history cleanly mapped to individual PRs.

More hardening: users with bypass permissions can merge the lowest unmerged PR in a stack; when a stack's base branch is deleted, the stack automatically retargets instead of closing its bottom PR (supporting "one stack branching off another"); auto-merge is rolling out over the next few weeks — select a group of PRs and they merge together once all are ready; stack context is now always visible in the PR page's persistent header and from the PR list view; Shift+J / Shift+K navigate between PRs in a stack; the timeline records PR join/leave events, and the pull_request webhook gains a stacked action; the gh stack extension supports Git worktrees with faster init, checkout, and navigation.

The announcement also carries two notable endorsements: Charlie Marsh, founder of Astral (OpenAI), said one merge was enough to convince him it's amazing; a Comcast engineer said seeing every branch in the stack right in the PR UI "makes managing and reviewing many dependent PRs far easier." Availability: all github.com plans, with GitHub Enterprise Server to follow in an upcoming release.

Why vibe coders should adopt it first

The pain point first: what AI agents are best at producing is giant diffs. Ask one to "refactor the auth module" and it grinds out a single PR touching 40 files and 2,000 lines — unreviewable in practice, so you merge it on vibes. That's the biggest source of quality incidents in vibe coding: not that the agent writes badly, but that humans can't keep up with reviewing.

Stacked PRs are the standard answer to that pain: have the agent deliver a big change as a chain of small PRs. Migrating the DB schema is one PR, adding the new API endpoint is one PR, rewiring the frontend calls is one PR — each independently reviewable and independently revertable. You start from the bottom PR and walk the logical chain upward; review cognitive load drops from "2,000 lines" to "200 lines at a time."

Practical advice: next time you ask an agent for a big change, put "deliver as stacked PRs" directly in the prompt — one concern per PR, with dependency relationships spelled out in the titles. Combined with this GA's auto-merge and single-merge-group queue behavior, upper PRs follow automatically once the bottom ones land; you just nod at each checkpoint. An order of magnitude more reliable than "one giant PR plus prayer."

One underrated fix: approvals surviving rebases. The vibe-coder norm is "agent changes → human reviews → agent changes again," with the base branch moving underneath as a matter of course. That used to mean approvals reset to zero and had to be re-earned; now they travel along, removing a big chunk of review friction. For human-machine iteration loops, that's a genuine experience repair.

One last thing: the toolchain is systematically adapting to the new reality of "AI produces giant changes" — stacked PRs cover the review side, Copilot dynamic workflows (which we covered yesterday) cover the process side. The second half of vibe coding won't be won by whoever has the most capable agent, but by whoever's engineering habits can catch what the agent produces. Those who learn to split PRs first collect the dividend first.