A large pull request is rarely difficult because of the code itself. The harder part is getting that code reviewed without making the reviewer understand half of the feature before they can comment on the first change.

A common example is a feature that touches a database schema, backend service, API contract, and UI. One developer may naturally build all four pieces in a single branch and then open one large pull request. Technically, the branch may be correct, but the review becomes harder. Reviewers have to jump between unrelated files, understand dependencies between changes, and wait for the entire feature before they can meaningfully review anything.

Stacked pull requests take a different approach. Instead of treating a large change as one reviewable unit, developers split it into a sequence of smaller pull requests where each change builds on the previous one.

GitHub has now made stacked pull requests generally available, giving teams a native way to manage this workflow instead of relying entirely on custom scripts, branch conventions, or third-party tooling.

What Are Stacked Pull Requests?

A stacked pull request is a series of dependent pull requests. Each pull request contains a relatively small change and is based on another branch rather than directly on the main branch.

For example, imagine a feature that needs three changes:

main
  |
  +-- feature/database
         |
         +-- feature/api
                |
                +-- feature/ui

You could create three pull requests:

PR #101: Database changes
PR #102: API changes
PR #103: UI changes

The API branch includes the database work, so PR #102 depends on PR #101. The UI branch includes both earlier changes, so PR #103 depends on PR #102.

The important part is that reviewers can start with the smallest logical unit instead of waiting for the complete feature.

Once PR #101 is merged, the dependency chain can move forward. The developer does not need to copy changes into new branches manually or create temporary patches just to keep the review process moving.

Why Stacked Reviews Matter

The problem with large pull requests is not simply the number of changed lines. A 500-line change can be easy to review if the changes are tightly related. Conversely, a 150-line pull request can be difficult when it mixes database changes, infrastructure configuration, API changes, and UI behavior.

Smaller pull requests reduce the amount of context a reviewer needs to hold at one time.

Consider a database migration followed by an API implementation. If both changes are in the same pull request, a reviewer has to understand the migration before evaluating whether the API implementation is correct. With stacked pull requests, the database change can be reviewed independently first.

That also changes the feedback cycle. A reviewer can identify a schema problem before the API work is finished. The developer can fix the foundation rather than discovering the problem after several additional commits have already been built on top of it.

This becomes particularly useful in larger teams where several people may review different parts of the same feature.

How a Stack Works

The basic workflow is straightforward.

Suppose you start from the main branch:

git checkout main
git pull

git checkout -b feature/database

You implement the database changes and push the branch:

git add .
git commit -m "Add order status table"
git push -u origin feature/database

You can now create the first pull request.

After that branch is ready, create another branch from it:

git checkout feature/database
git checkout -b feature/api

Implement the API changes:

git add .
git commit -m "Add order status API"
git push -u origin feature/api

The second pull request is now based on the first branch.

You can continue the same pattern:

git checkout feature/api
git checkout -b feature/ui

The resulting relationship looks like this:

main
  |
  +-- feature/database
          |
          +-- feature/api
                  |
                  +-- feature/ui

This is the fundamental Git structure behind stacked pull requests. The GitHub workflow builds on that dependency relationship to make the pull requests easier to manage.

The Important Difference From Three Independent Pull Requests

It is tempting to think that stacked pull requests are simply three smaller pull requests. They are not.

If you create three independent branches from main, you have:

main
 |--- feature/database
 |--- feature/api
 |--- feature/ui

Each branch is expected to stand on its own.

With stacked pull requests, the branches form a dependency chain:

main
 |
 +--- database
       |
       +--- api
             |
             +--- ui

That distinction matters because the later changes may not work independently.

For example, the API might call a database column introduced by the first branch. Reviewing the API branch without the database change would therefore be misleading.

A stack makes that dependency explicit.

Keeping Reviews Small Without Hiding Complexity

One of the strongest reasons to use stacked pull requests is review quality.

Imagine an authentication feature requiring:

  1. Database schema changes

  2. Domain model changes

  3. Service-layer implementation

  4. API endpoints

  5. Tests

  6. UI changes

A single pull request might contain dozens of files. The reviewer can technically inspect everything, but the cognitive cost is high.

A stack could instead look like:

PR 1: Add authentication database model
PR 2: Add authentication service
PR 3: Add authentication API
PR 4: Add authentication tests
PR 5: Add authentication UI

Each pull request has a clearer purpose.

The reviewer can concentrate on whether the database design is correct before moving to service behavior. The next reviewer can focus on API design without spending time rediscovering the schema.

This does not remove complexity from the feature. It organizes the complexity into smaller review boundaries.

What Happens When the First Pull Request Changes?

This is where stacked workflows require some discipline.

Suppose PR 1 contains a database change and PR 2 contains API changes that depend on it. A reviewer asks for a modification to PR 1.

That modification changes the base of PR 2.

The developer therefore needs to keep the stack synchronized. Git operations such as rebasing or updating dependent branches become part of the workflow.

For example:

git checkout feature/database
git pull

After updating the first branch, the dependent branch may need to be rebased:

git checkout feature/api
git rebase feature/database

The exact workflow depends on how the team manages branches and how GitHub's stacked pull request tooling is being used, but the underlying principle remains the same: changes to an earlier branch can affect every branch above it.

This is the main trade-off developers should understand before adopting the workflow.

Stacked Pull Requests and Merge Order

A stack has an inherent order.

If the branches look like this:

main
 |
 +-- A
     |
     +-- B
         |
         +-- C

then B depends on A, and C depends on B.

That means merging C before A generally does not make sense from a dependency perspective. The changes need to be integrated in a way that preserves the intended relationship.

This is one reason stacked workflows work best when each layer represents a logical increment rather than an arbitrary chunk of code.

For example, these are reasonable layers:

Database
   ↓
Domain
   ↓
Service
   ↓
API

But splitting a single method into three unrelated pull requests simply to reduce the line count does not necessarily improve review quality.

The goal is not "small pull requests at any cost." The goal is small, understandable review units with clear dependencies.

Stacked Pull Requests With Tests

Tests deserve special consideration.

A developer might create a stack where the implementation comes first and tests come later. That can make review easier in some cases, but it can also create an intermediate branch that is difficult to validate.

For example:

PR 1: Add payment service
PR 2: Add payment API
PR 3: Add integration tests

If PR 1 introduces behavior that requires tests to verify an important security or business rule, waiting until PR 3 may not be ideal.

A better stack might be:

PR 1: Add payment domain behavior + unit tests
PR 2: Add payment API
PR 3: Add integration coverage

The same engineering principle applies as with normal pull requests: each review should provide enough context to determine whether the change is correct.

Common Mistakes

Making the Stack Too Deep

A stack of two or three pull requests can be easy to understand. A stack containing ten or fifteen dependent branches becomes much harder to maintain.

Every change near the bottom can potentially affect everything above it.

If a stack becomes very deep, it is worth asking whether some branches can be merged independently or whether the feature should be reorganized.

Splitting Changes Artificially

Not every file needs its own pull request.

Creating:

PR 1: Add class
PR 2: Add method
PR 3: Rename property
PR 4: Add test

does not automatically produce better reviews.

A reviewer may actually spend more time moving between pull requests than they would have spent reviewing the complete change.

The useful boundary is usually a logical change, not a fixed number of lines.

Ignoring Branch Dependencies

A later pull request may contain changes from earlier branches. Developers sometimes forget this and assume the later branch represents only its own commits.

Before reviewing or debugging a stacked PR, it is worth understanding its base branch.

Otherwise, a reviewer may report code as missing when it actually exists in an earlier pull request.

Treating Stacking as a Replacement for Good Git Practices

Stacked pull requests do not eliminate the need for clean commits, meaningful branch names, careful rebasing, or understanding Git history.

They make a particular workflow easier, but they do not change the underlying Git model.

If a team already struggles with unclear commits and frequently rebased branches, adding another layer of workflow can increase confusion rather than reduce it.

Advantages and Disadvantages

Advantages

Smaller review units: Reviewers can focus on one logical change instead of understanding an entire feature at once. This is especially useful when a feature crosses several architectural layers.

Earlier feedback: A foundational change can be reviewed while higher-level work is still being developed. Problems in database or domain design can therefore be identified earlier.

Clear dependencies: The branch structure shows which changes depend on others. This can make a complicated feature easier to reason about during development and review.

Better collaboration: Different reviewers can concentrate on different parts of a feature without requiring everyone to understand the complete implementation immediately.

Disadvantages

More Git complexity: Developers need to understand branch relationships, rebasing, synchronization, and merge order. That adds operational overhead compared with a single branch.

Changes propagate through the stack: A modification to a lower-level pull request can require updates to every dependent branch.

Deep stacks become difficult to manage: The workflow becomes less attractive when a feature requires a long chain of dependent pull requests.

Review context can become fragmented: If the stack is split poorly, reviewers may have to jump between multiple pull requests to understand one logical behavior.

When Should You Use Stacked Pull Requests?

Stacked pull requests make the most sense when a feature naturally contains several dependent pieces that can be reviewed independently.

They are particularly useful for larger application changes, cross-layer development, infrastructure changes followed by application changes, and work where early review of foundational code can prevent expensive rework later.

They are less useful for small bug fixes, isolated changes, or work that can already be represented cleanly by one conventional pull request.

The decision should be based on the dependency structure of the work, not simply on the number of changed lines.

Summary

GitHub's generally available stacked pull request workflow addresses a problem that becomes increasingly visible as software changes get larger: a feature may be logically composed of several changes, but traditional pull requests often force those changes into one large review.

Stacking allows developers to represent the dependency chain directly. A database change can sit underneath an API change, which can sit underneath a UI change, while each layer gets its own review boundary.

The workflow does introduce additional Git complexity. Rebasing, branch dependencies, merge order, and stack maintenance become important, particularly when changes are requested in an earlier pull request.

Used carefully, stacked pull requests are less about creating more pull requests and more about creating better review boundaries. The strongest stacks are built around logical engineering changes, keep dependencies understandable, and remain small enough that the team can maintain them without turning Git management into another source of friction.