GitHub Stacked Pull Requests Are Now Generally Available

GitHub has made stacked pull requests generally available. The feature is designed for large changes that are difficult to review as one enormous pull request: developers can split the work into smaller dependent pull requests, review them independently and merge the stack together.

That is a workflow improvement more than a flashy feature. Large code changes create review fatigue, hide important details and often force reviewers to understand too much context at once. Stacks try to make the same change easier to inspect without forcing developers to artificially separate work that actually depends on earlier steps.

What a stacked pull request is

A stack is a sequence of pull requests where later changes depend on earlier ones. Instead of waiting for the entire feature to be finished before opening one huge review, a developer can create a chain of smaller pieces.

Each pull request can focus on one understandable step: infrastructure, data model, API, interface or cleanup, for example.

GitHub says stacks are already widely used

GitHub reports that repositories using stacks during preview saw higher merged-code volume compared with peers, and that many of the largest repositories have adopted stacked pull requests.

Those numbers do not prove that stacks are right for every team, but they suggest the workflow is solving a real problem at scale.

The general release improves rebasing

GitHub says approvals can now remain in place when unchanged code is rebased after the base branch moves. Rebased commits also retain signatures.

That matters because rebasing a stack can otherwise create unnecessary review churn. If the underlying reviewed code did not change, forcing reviewers to repeat approvals adds process without adding safety.

Stacks change how work is planned

To use stacks well, developers need to think about the sequence of a change. Each step should be independently understandable and keep the repository in a reasonable state.

That planning can be beneficial by itself. Breaking a large feature into reviewable layers often reveals where responsibilities are mixed or where a change has become too broad.

Reviewers still need the big picture

Smaller pull requests reduce cognitive load, but they can also hide system-level consequences if every review is considered in isolation.

Teams should preserve a clear description of the overall goal and show reviewers how each pull request fits into the stack.

When stacks are worth using

Stacks make the most sense for large refactors, migrations, multi-layer features and changes where several pieces must land in order.

For a tiny bug fix, the extra structure may be unnecessary. Like most workflow tools, the value appears when the coordination problem is large enough to justify it.

Sources and further reading

Read GitHub's stacked pull requests announcement

Explore more articles on the Nejma Blog

Visit Nejma