GitHub’s Stacked Pull Requests Make Review the Unit of Work

A large pull request asks a reviewer to hold several stories in their head at once: why the data model changed, whether the API is compatible, and whether the interface handles the new behavior. Even when every line is reasonable, the combined decision can be difficult.

GitHub made stacked pull requests generally available on October 6. The announcement matters because dependent changes now have a first-class review workflow. My interest is less in producing more pull requests than in giving each review a question someone can actually answer.

Split at a decision boundary

Imagine adding saved searches to an application. One layer introduces a persistence model and migration. Another exposes the API. A third adds the interface. These are related changes, but they require different kinds of scrutiny.

The database review asks about constraints and migration behavior. The API review asks about authorization and response contracts. The interface review asks about loading, empty, and failure states. A stack can make that sequence visible without requiring the entire feature to fit into one review.

That is an illustrative design, not a rule that every feature needs three layers. A migration and its application code may need to ship together. A tiny refactor might be easier to understand in a single pull request. The right boundary is where the reviewer’s question changes, rather than an arbitrary line-count target.

Dependencies remain real

In GitHub’s stack workflow, each upper pull request targets the branch below it. Reviewers see the diff for that layer, while the stack provides the larger context. Layers can land together or in stages under repository requirements.

This helps with presentation; it does not remove coupling. Changing an API contract near the bottom can invalidate assumptions above it. I would put a short dependency note in each description: what this layer needs, what it guarantees, and what remains unfinished.

For the saved-search example, the API layer should explain whether existing clients tolerate the new response shape. The interface layer should say whether it can run against the old server. Those details determine whether partial merging is safe.

The useful part of the GA release

The October release preserves approvals when rebasing an otherwise unchanged stack after its base advances. It also puts a stack through the merge queue as a single merge group. GitHub says stack auto-merge is rolling out over the following weeks, so I would check its availability before depending on it.

These details address ordinary friction: repeating an unchanged review, or worrying about how dependent layers enter the queue. They make stacks easier to use within an existing repository workflow rather than as a separate bookkeeping system.

My takeaway is to keep CI aligned with the dependency structure. Test a layer with its prerequisites, and test the assembled feature as well. A green isolated diff does not demonstrate that the migration, API, and interface agree.

Make the review request useful

Before opening a stack, I would write its intended sequence in plain language:

Add storage without changing existing behavior.

Add authenticated API operations and failure handling.

Expose the feature in the interface and test the complete journey.

Then I would check whether those statements are true. If the first layer breaks the old application, it is not independently safe merely because it is small. If the second layer contains unrelated cleanup, that cleanup should probably move elsewhere.

For agent-generated code, this becomes especially valuable. Ask for the decomposition before asking for implementation. Review the proposed dependency boundaries, then insist that each layer explain its behavior and validation. An agent can split a patch mechanically; the human still has to decide whether the split makes sense.

A better place to start

I would trial stacks on one substantial feature with understandable dependencies, rather than turn every change into a stack. Watch whether reviewers understand the sequence, whether feedback propagates cleanly, and whether partial merges create awkward intermediate states.

The goal is a review that ends with a justified decision. Smaller diffs help only when they make that decision clearer. GitHub’s release gives teams a better container for that work; the architecture and explanations inside it are still ours to write.

Sources

GitHub GA announcement: https://github.blog/changelog/2026-10-06-stacked-pull-requests-generally-available/

GitHub stack workflow: https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/