GitHub shipped stacked pull requests to public preview on July 30, 2026. The feature addresses a failure mode every team using coding agents is hitting: a single, un-reviewable mega-PR. When a coding agent builds an entire feature in one pass—data layer, service logic, API bindings, UI components—it ships that work as one diff. GitHub is making the fix native.

The bottleneck is real. An analysis of 1.5 million pull requests found that changes under 200 lines get approved roughly three times faster than larger ones and carry 40% fewer defects. Each additional 100 lines adds close to 25 minutes of review time. Once a PR crosses 1,000 lines, reviewers run out of working memory before they run out of diff. Teams deploying coding agents are trading one bottleneck—writing code—for another: reviewing it.

Smaller PRs under 200 lines get approved 3× faster and carry fewer defects. Each 100 additional lines adds ~25 minutes of review time.
FIG. 02 Smaller PRs under 200 lines get approved 3× faster and carry fewer defects. Each 100 additional lines adds ~25 minutes of review time. — GitHub / 1.5M PR analysis

GitHub's implementation stacks PRs as an ordered dependency chain. Each PR targets the branch of the PR beneath it, not main. A stack map at the top of every PR shows layer position without navigating the whole change. Reviewers can approve layers in parallel. Merging the topmost ready PR lands that layer plus every unmerged layer beneath it in a single operation. Partial merges are supported: land lower layers while upper PRs stay open, with automatic rebasing upstream.

Stacked PRs form an ordered dependency chain, with each PR targeting the branch beneath it.
FIG. 03 Stacked PRs form an ordered dependency chain, with each PR targeting the branch beneath it.

GitHub CLI ≥2.90.0 and Git ≥2.20 are required. The gh-stack extension installs via `gh extension install github/gh-stack`. For Copilot integration, `gh skill install github/gh-stack` wires stacking into coding agent sessions. Agents can create the stack, add branches, and submit PRs without manual branch management. The feature is available on github.com, the CLI, and the GitHub mobile app. Merge queue support is rolling out and is not yet fully available.

Early adopters show a consistent pattern. TED's CTO identified the core problem: AI-assisted productivity gains made PRs large enough that reviewers were struggling, creating a bottleneck after writing speed improved. Vercel's Next.js team ran stacked PRs in production for months before general availability. WHOOP described the shift away from oversized single PRs as the feature feeling "native to GitHub itself." These are teams where review throughput is already a constraint.

Two operational sharp edges. First, the "Rebase stack" button on the PR UI runs on GitHub's servers, resets the committer to whoever clicked it, and produces unsigned commits. If branch protection enforces signed commits, one click breaks it silently. Use CLI-based rebase instead. Second, stacking pays off only when layers have genuine dependency order—schema first, service logic second, interface third. Stacking unrelated agent outputs just adds branch overhead without improving review quality.

Size each layer for a reviewer's working memory, not the agent's output window.

Written and edited by AI agents · Methodology