Stacked Pull Requests: Shipping Smaller Changes Without Waiting on Review

Stacked pull requests let you keep building on top of code that is still under review, so you never sit blocked waiting for a teammate to approve your last change. The video is a two-person skit where one developer explains GitHub's newly released stacked PR feature to a skeptical coworker. It walks through the everyday problem of a large task, a slow review queue, and the second PR that gets stuck behind the first. The core pitch is that you can now break one big change into a chain of small, dependent PRs that each get reviewed on their own.

The Problem Stacked PRs Solve

The video frames a scenario every working developer recognizes. You get assigned a fairly large task and open a PR for the first slice of it. You submit it for review, but your teammates already have other changes in their queue, so it takes anywhere from a couple hours to a couple days to get looked at. During that wait you do not want to start the next PR, because if the first one needs changes, everything built on top of it has to change too. So you end up blocked, sitting idle while your own code waits in line.

Stacked PRs remove that wait. Instead of pausing, you open a second PR on top of the first one. The second PR only contains the new changes layered on the first. When the first PR gets feedback and updates, the stack carries those updates forward. You keep moving instead of stalling.

How the Stack Is Structured

The on-screen diagram makes the structure concrete. It shows a task coming in from Jira ("build new microservice"), a developer creating the first PR, and then a stack of PRs chained on top of each other, each targeting the one below it. The example in the video splits a feature into three layers: a database change at the bottom, an API-level change on top of that, and a front-end change on top of that. Each layer is its own PR with its own focused diff.

The payoff shows up on the reviewer side. Rather than one giant pull request touching the database, the API, and the UI all at once, a reviewer gets three small PRs and can approve each part individually. The diagram labels this directly as "smaller changes." Small, single-purpose diffs are faster to read and easier to reason about than one sprawling change set.

Why This Is More Than Just Branches

The skeptical coworker raises the obvious objection: you could already do this with plain git branches. The response in the video is honest. Yes, you could, but managing a chain of dependent branches by hand was a pain. When the bottom branch changed, you had to rebase every branch above it yourself and keep the whole chain in sync manually.

The difference now is that stacking is a first-class feature with dedicated commands. GitHub's implementation handles the chain for you through the gh stack CLI extension and support directly in the GitHub UI. The dependency relationships, the rebasing, and the merge order stop being manual bookkeeping. That shift from a manual workaround to a supported workflow is the actual news here.

The AI Angle

The most forward-looking point in the video is why this feature is arriving now. With AI coding assistants, developers are generating far more code than before. The video points out that you can hand a task to an agent and get a 4,000-line PR back in 20 minutes. A diff that size is nearly impossible to review well. Reviewers skim it, miss things, and rubber-stamp it because reading all of it carefully is not realistic.

Stacked PRs give a structural answer. You can have the agent break that 4,000-line change into several smaller, logically separated PRs. Each one stays small enough for a human to actually review. As AI pushes output volume up, the bottleneck moves from writing code to reviewing it, and stacking is one way to keep review manageable.

Key Takeaways

Stacking removes the review wait. You build the next PR on top of the current one instead of sitting blocked while a teammate works through their queue.
Each PR stays small and focused. Splitting a feature into a database PR, an API PR, and a front-end PR lets reviewers approve each layer on its own.
It is a first-class feature now, not a manual trick. Dependent branches were always possible, but dedicated commands and automatic rebasing remove the manual bookkeeping that made the pattern painful.
AI code volume is the driver. When an agent can produce a 4,000-line PR in minutes, breaking that output into reviewable chunks becomes the real constraint.
The reviewer is the real beneficiary. Small, single-purpose diffs are faster to read and easier to reason about than one sprawling change set.