Every engineering team eventually discovers the same uncomfortable review problem. A change is too large for one pull request, but too connected to become a pile of unrelated branches. Split it badly and reviewers lose the story. Keep it together and the diff becomes something people postpone until it has already gone stale.

That is why the August 3 DevOps.com item on GitHub bringing stacked pull requests into native workflow is more than a feature announcement. GitHub's own July 30 changelog says stacked pull requests are now in public preview, with rollout to repositories over the following days. The core idea is simple: represent a larger change as an ordered set of small pull requests, where each layer builds on the one beneath it.

Stacking has existed for a long time outside GitHub's first-party product surface. Large engineering organizations have used similar workflows internally, and open-source developers have built local tooling around branch chains. The important change is that GitHub is making the dependency shape visible where review already happens.

one large feature
  schema change
  service logic
  API adjustment
  UI behavior
  cleanup

old failure mode
  one giant PR
  slow review
  stale feedback
  risky merge

stacked PR workflow
  five focused PRs
  dependency order preserved
  checks still run
  reviewers inspect one layer at a time
The useful unit is not always the whole feature. It is the smallest layer that can be reviewed without losing context.

Small Diffs Need A Map

The weakest version of stacked development is just a convention in people's heads. One branch targets another branch. A reviewer is told to start at the bottom. Someone rebases the middle. A required check moves. A merge lands out of order. The workflow can be powerful, but without product support it becomes tribal knowledge with sharp edges.

GitHub's preview focuses on making that shape explicit. The changelog describes stack maps at the top of pull requests, independent layer review, partial stack merges, automatic retargeting and rebasing when lower layers land, and compatibility with existing reviews, branch protections, checks, and merge requirements. The related GitHub Docs section now treats stacked PRs as a first-class pull request workflow rather than an external trick.

The gh-stack CLI extension is also part of the story. GitHub says developers can create stacks from the terminal or from GitHub, then review layers on the web, mobile, or CLI surfaces. That matters because stacks are most useful when they do not require every contributor to adopt a separate review tool just to understand the dependency graph.

A stack is not only a smaller diff. It is a promise that the dependency order remains visible while the review stays narrow.

The AI Angle Is Review Pressure

DevOps.com frames one pressure clearly: coding tools can now produce larger chunks of code faster than many teams can review them. That does not make stacked PRs an AI feature in the narrow sense. It makes them a review-control feature for a world where output volume is rising.

If a coding agent generates a whole feature, the worst default is dumping the entire thing into one enormous PR. The reviewer has to reconstruct the architecture, verify the foundation, check the surface behavior, and detect subtle dependency mistakes all at once. A good stack gives the work a sequence: migration first, core logic next, API boundary after that, interface last. Reviewers can reject the base layer before arguing about polish on top of it.

That does not remove judgment from the process. In fact, it raises the bar on change design. A bad stack can still hide a sprawling idea behind five small diffs. A good stack makes each layer independently understandable while preserving why the layers belong together.

What Teams Should Watch

  • Stack boundaries: each PR should have a reason to exist beyond keeping line counts low.
  • CI cost: running checks across dependent branches can multiply feedback time if pipelines are already heavy.
  • Merge policy: partial stack merges are useful only when lower layers are valuable on their own.
  • Reviewer routing: different layers may need different reviewers, especially when schema, backend, frontend, and operations work share one feature.
  • Agent output: generated changes should be organized into reviewable layers before they become a trust problem.

The Takeaway

Native stacked pull requests are a small workflow feature with a large social effect. They acknowledge that software changes are often sequential, not flat. They also acknowledge that review quality depends on the size and shape of the unit in front of the reviewer.

GitHub is not inventing stacked review. It is moving a proven pattern into the place many teams already coordinate code. If the preview works well, the benefit will not be that developers can open more pull requests. The benefit will be that large changes can move through review without pretending to be smaller than they are or forcing everyone to swallow the whole thing at once.

Good review tooling does not make hard changes easy. It makes the hard parts visible in the right order.

Sources