Beyond the News
Sign in
Web DevelopmentDeveloper Tools Active dossier

GitHub makes stacked pull requests a native production workflow

GitHub's stacked pull requests have moved out of preview, giving teams a first-party way to split one dependent change into smaller reviewable layers while preserving repository checks and coordinated merging.

Reviewed and published by Lars Jansen Updated 3 min read
Comment
First published

Key details

  1. GitHub stacked pull requests reached general availability on October 6, 2026.
  2. Stacks represent dependency-ordered pull requests for a larger change.
  3. GitHub's async merge API supports stacked pull requests and became generally available October 1.
  4. The async API is GitHub's recommended path for programmatic pull-request merging and the only merge API supporting stacks.

What builders should take away

  1. Use stacks when a large change has real dependency layers that can each form a coherent review unit.
  2. Keep each layer independently understandable and testable rather than using stacks to hide unrelated work.
  3. Automation that lands stacks should use GitHub's async merge API rather than older synchronous merge paths.
  4. For coding-agent workflows, design the agent's output around review boundaries instead of only optimising generation speed.

What changed

GitHub moved stacked pull requests from public preview to general availability on October 6. A stack represents a dependency-ordered series of pull requests for one larger change, letting reviewers inspect smaller focused diffs while GitHub tracks the relationship between layers. GitHub's async merge API, made generally available October 1, can merge stacked pull requests and is the recommended programmatic merge path; it is the only GitHub merge API that supports stacks.

Why it matters

Large AI-assisted changes increasingly move the bottleneck from writing code to reviewing it. Native stacks let teams preserve dependency relationships without forcing reviewers through one giant diff or relying on an external stacking service. General availability removes the preview boundary for teams that want to standardise the workflow, while the async merge API gives automation a supported path for landing stacks.

One change can stay coherent without becoming one giant PR

Each pull request in a stack represents a focused layer and depends on the layer below it. Reviewers can reason about smaller diffs while the overall change remains explicitly connected.

The merge path is now programmable

GitHub's generally available async merge API supports individual and stacked pull requests, merge queues and permitted rules bypass. GitHub recommends it over the older synchronous REST endpoint or GraphQL mutations for programmatic merging.

Agent-generated code makes review structure more important

Faster code generation does not remove human review constraints. Stacks provide a way to break agent-produced work into dependency-aware review boundaries instead of accepting a single oversized pull request.

What to watch next

  • Adoption of stacked PRs in agent-heavy development teams.
  • Changes to gh-stack tooling and merge-queue behaviour after general availability.
  • Whether GitHub exposes more stack-aware policy and analytics controls.

Still unclear

  • The exact productivity effect depends on repository practices and change structure; general availability does not make stacking appropriate for unrelated work.
  • Third-party workflow integrations may differ in how fully they understand stack relationships.

Sources

Direct reading behind this dossier.

2 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment
Continue reading
Artificial Intelligence

GitHub Copilot code review can now approve pull requests

Copilot code review now moves from advisory assessment toward a governed merge gate. The public preview remains off by default, and GitHub’s current docs let administrators separate AI approval itself from whether that approval counts toward required-review policy.