DEV Community

Cover image for GitHub: Stacked Pull Request
Tito
Tito

Posted on

GitHub: Stacked Pull Request

#productivity #github #git #ai

Introduction

The software development life cycle has changed dramatically over the past couple of years. Agentic development workflows and more recently, ideas like loop engineering from the Anthropic team,have pushed engineering productivity to levels we've never seen before. Features that used to take a sprint now ship in an afternoon.

But here's the catch: writing code got faster. Reviewing it didn't.

For teams using GitHub, this creates a painful bottleneck. A big feature lands as one giant pull request, a reviewer stares at a 1,500-line diff, sighs, and moves it to "later." Meanwhile, the author is blocked. They can't build on top of unreviewed work without juggling branches and rebasing by hand. The result? Growing backlogs, blocked developers, and that all-too-familiar wait-for-PR-review limbo.

There's actually data behind this pain. One analysis of 1.5 million pull requests found that PRs under 200 lines get approved roughly three times faster and carry about 40% fewer defects. Past 1,000 lines, reviewers simply run out of mental bandwidth to catch real problems.

On July 30, 2026, GitHub shipped a native answer: Stacked Pull Requests, now in public preview and rolling out to all repositories. The stacked-diff community (Graphite, Sapling, git-branchless) has been building third-party tooling around this idea for years. Now it's built directly into GitHub: web,CLI,mobile, and even coding agents like Copilot via the gh-stack skill.

What Is a Stacked Pull Request?

A stacked pull request is an ordered series of pull requests, where each PR represents one focused layer of a larger change, and each PR targets the branch of the PR below it.

Instead of this:

main ← one-massive-1500-line-pr
Enter fullscreen mode Exit fullscreen mode

You get this:

main ← db-schema ← api-endpoints ← frontend-ui
Enter fullscreen mode Exit fullscreen mode

Three small PRs. Each one has its own focused diff. Your teammates can review the database layer, the API layer, and the UI layer independently and in parallel,and when everything is approved, the whole stack merges in one click.

Because it's native to GitHub, your existing branch protections, required checks, and review rules all keep working. Nothing about how you protect main changes.

How We Do It: Step by Step

Let's walk through building a real stack. Imagine we're shipping a "user notifications" feature made of three logical layers: the database schema, the API endpoints, and the UI.

Prerequisites

  • GitHub CLI (gh) version 2.90.0 or later, and Git 2.20 or later if you have not installed, use this commands: on Unix-based 
sudo apt install gh
Enter fullscreen mode Exit fullscreen mode

on Mac

brew install gh
Enter fullscreen mode Exit fullscreen mode

on Windows:

winget install GitHub.cli
Enter fullscreen mode Exit fullscreen mode
  • Authenticated CLI: gh auth login
  • A repository you can push to (all branches must live in the same repo,cross-fork stacks aren't supported)

Step 1: Install the CLI extension 

gh extension install github/gh-stack
Enter fullscreen mode Exit fullscreen mode

That's it. GitHub claims you can create your first stack in under a minute and honestly, they're not exaggerating.

Step 2: Initialize the stack

Navigate to your repository and run:

gh stack init
Enter fullscreen mode Exit fullscreen mode

You'll be prompted to name your first branch (let's call it notifications-db-schema). This creates a tracking entry and checks out the first branch on top of your trunk (by default, your repo's default branch like main — but a stack can target any branch).
Step 3: Work on your first layer
Nothing new here — write code, stage, commit, exactly as you always do:

... write the migration and models ... 

git add .
git commit -m "Add notifications table and model"
Enter fullscreen mode Exit fullscreen mode

Step 4: Add the next layer on top

When you're ready for the next logical unit of work, add a new branch on top of the current one:

gh stack add notifications-api
Enter fullscreen mode Exit fullscreen mode

... write the endpoints ... 

git add .

git commit -m "Add notifications REST endpoints"
Enter fullscreen mode Exit fullscreen mode

Pro tip: gh stack add -Am "message" stages everything, commits, and creates the next branch in a single step. No separate git add / git commit needed.

Repeat for the UI layer:

gh stack add notifications-ui

... build the UI ... 

git add .

git commit -m "Add notifications dropdown component"
Enter fullscreen mode Exit fullscreen mode

Our local stack now looks like:

main ← notifications-db-schema ← notifications-api ← notifications-ui
Enter fullscreen mode Exit fullscreen mode

You can check it anytime with:

gh stack view
Enter fullscreen mode Exit fullscreen mode

This shows the branch tree, where you currently are, and any associated PR numbers. You can also hop around the stack with gh stack up, gh stack down, gh stack top, and gh stack bottom.

Step 5: Push everything and create the PRs

One command:

gh stack submit
Enter fullscreen mode Exit fullscreen mode

This pushes every branch to the remote (in parent-to-child order) and creates all the pull requests on GitHub. Each PR gets the correct base branch automatically — notifications-api targets notifications-db-schema, not main — so reviewers only see the diff for that specific layer. The PRs are automatically linked together as a stack.

Made more changes later? Just run gh stack submit again and everything updates.

Step 6: Review each layer independently

Open any PR in the stack on github.com and you'll see a stack map at the top of the merge box. It shows every PR in the stack, its status, and lets you jump to any layer with one click.

This is where the magic happens for teams: one teammate can review the schema PR while another reviews the API PR — in parallel, without blocking each other, and without anyone having to hold a 1,500-line diff in their head.

Step 7: Merge — one, some, or all

You've got options:
Land the whole stack: merge the topmost ready PR, and GitHub lands it plus every unmerged layer below it in a single operation.
Land part of the stack: merge one or more lower layers. The PRs above stay open, and GitHub automatically rebases and retargets them. No manual rebase gymnastics.

Your branch protections and required checks still govern everything that reaches main.

After a merge, sync your local state:

gh stack sync
Enter fullscreen mode Exit fullscreen mode

This fetches, reconciles with GitHub, rebases what's left, and refreshes PR state. Add --prune to clean up local branches for merged PRs.

No CLI? No Problem

You can build a stack entirely from github.com: just set the base branch of each new PR to the branch of the PR below it. GitHub recognizes the chain and even shows a recommendation banner offering to turn already-open, lined-up PRs into a stack. Stacks also work from the GitHub mobile app and from coding agents like Copilot using the gh-stack skill.

Conclusion

Stacked Pull Requests attack the real bottleneck of the agentic era: not writing code, but getting it reviewed and merged safely. Instead of hoping reviewers can scale their attention to match ever-larger diffs, the tooling itself now enforces decomposition and enables parallel review by default.

Top comments (0)