What Are Stacked Pull Requests (PRs)?

Stacked PRs (stacked pull requests) are a chain of small, dependent pull requests that together make up one larger change. The bottom PR usually targets the main branch, and each PR above it targets the branch of the PR below.

Each PR in the stack shows only the diff for its own layer. Reviewers can read and approve one small change at a time while the author keeps building on top.

Stacks also help teams across time zones, since lower layers get reviewed while the author works on the next one; see code review tools for distributed teams.

The idea is also called stacked diffs, a name that comes from commit-based review tools.

What Changed in Stacked PRs in 2026

At the start of 2026, neither major Git host supported stacked PRs natively, so teams relied on third-party CLIs and manual retargeting. During the year, both built stacking in, driven by the volume of AI-generated code.

Both major Git hosts made stacking a built-in feature within about four months:

• GitLab moved first: GitLab 19.1 added stacked merge requests in the merge request UI on all tiers, showing each merge request’s position in the stack, with up to 20 per stack (June 18, 2026, GitLab 19.1 release notes).
• GitHub followed in preview: native stacked pull requests went into public preview, with the gh stack extension for GitHub CLI (July 30, 2026, GitHub).
• GitHub then shipped stacks to everyone: stacked pull requests became generally available on all its cloud plans, with merge queue support for whole stacks and approvals kept across rebases (October 6, 2026, GitHub).

Early data links stacks to modest gains. GitHub reported 9% more merged code in repositories using stacks than in peers, and a 5% improvement in time to merge in the top repositories that use them (October 6, 2026, GitHub).

With stacks now built in, more changes arrive as chains of small PRs, so review has to keep each layer in context.

How Stacked PRs Work

A stack is built from the bottom up. Foundational changes, such as shared types or a database schema, go in the lowest branch, and code that depends on them, such as API routes or UI, goes higher, as GitHub’s documentation describes.

A bottom layer that changes a shared type can cause a breaking change in the layers above.

feat/frontend       -> PR 3 (base: feat/api-endpoints)   top
feat/api-endpoints  -> PR 2 (base: feat/auth-layer)
feat/auth-layer     -> PR 1 (base: main)                 bottom

The usual workflow looks like this:

1. Create a branch for the first layer and open a PR against main.
2. Create the next branch on top of it and open a PR against the first branch.
3. Keep adding layers, one focused change each.
4. When a lower PR changes, rebase the layers above it.
5. Merge from the bottom up, so each remaining PR retargets the branch below.

Stacked PRs vs Stacked Diffs

The two terms describe the same idea at different units of review.

GitLab’s CLI can turn each diff into its own merge request, and GitLab shows them as stacked merge requests (last checked October 2026, GitLab’s docs).

Stacked PRs vs One Large PR vs a Feature Branch

Benefits and Drawbacks of Stacked PRs

Benefits

• Smaller reviews. Each layer is a focused diff, which is easier to read closely. See reviewer fatigue.
• Less waiting. Authors keep building on open work while earlier PRs are in review, which can shorten lead time, one of the DORA metrics.
• A natural fit for agents. An agent can open one PR per task, each based on the one below, which keeps every review small.

Drawbacks

• Rebase work. A change in a lower layer ripples up through every layer above it.
• Lost context. A reviewer who sees only one layer can miss how it fits with the rest.
• Coordination. Tooling, branch rules, CI and the CODEOWNERS file need to apply to each layer correctly.

Qodo’s Take: Stacks Shrink Each Review, so Reviewers Need to See How the Layers Connect

Stacking solves one problem well: no single review is too big to read. Stacking also creates a new one. A layer can look fine on its own and still break something two layers up.

A good review process keeps each layer small and keeps the whole stack in view, with context from the wider codebase. For large repositories, see AI code review tools for GitHub monorepos.

Qodo helps with the queue and with each layer. PR Triage, in Research Preview, groups related PRs by stack so a lead can work through them in order. PR Triage prioritizes and routes; it doesn’t review a stack as one unit.

Teams whose agent pipelines generate very large PRs often look to stacking to keep each review readable. Qodo doesn’t document a stacked-PR feature: it reviews each PR in a stack on its own, with codebase context, and leaves the stack structure to the Git host.

Qodo is the best AI code review platform to keep stacked PRs moving because PR Triage, in Research Preview, groups related PRs into stacks in one queue across Git providers, with each PR’s findings and review SLA visible, so a lead can review in order and unblock the bottom of the stack first.

Qodo Groups Stacks in PR Triage

PR Triage brings open pull requests from GitHub, GitLab, Bitbucket and Azure DevOps into one queue and groups them By PR Stacks by default. Expanding a stack shows its related PRs (last checked October 2026, Qodo’s docs). PR Triage is a Research Preview and is open to admins by default.

Qodo Reviews Each Layer Before It’s Pushed

Qodo’s Reviewer skill, in Beta, lets a coding agent review local changes before pushing, so each layer arrives with fewer issues (last checked October 2026, Qodo’s docs). See pre-PR and local code review.

Qodo Reviews Every PR in the Stack

Every PR in a stack gets Qodo’s standard review, with codebase context and, once Rule enforcement is on, the team’s rules (Qodo’s docs). See full codebase context vs diff-only review.

Qodo Example: The Type Change in Layer One

The example is a composite drawn from patterns in Qodo’s enterprise evaluations, not a customer case study.

A tech lead whose agent pipeline generates very large PRs splits the work into stacks so each review stays readable.

An engineer splits a refunds feature into four layers. Before pushing layer one, a schema change, their agent runs Qodo’s Reviewer skill and fixes a missing index. In PR Triage, the tech lead sees all four PRs grouped as one stack and reviews them in order.

Ways to Review Stacked PRs

The table compares common ways teams review stacks.

Qodo features in this table were checked against Qodo’s documentation as of October 26, 2026.