Large software changes create an awkward choice. A developer can open one enormous pull request that is difficult to review, or split the work across several branches and accept the job of keeping them synchronized.
GitHub is now trying to remove that trade-off. On July 30, the company placed stacked pull requests in public preview. The feature lets developers arrange a sequence of related pull requests as layers of one larger change. Each layer can be reviewed on its own, while GitHub keeps its position in the sequence visible.
This is not a new programming technique. Tools such as Graphite and Sapling have supported versions of stacked development for years. What is new is that the workflow now lives inside GitHub’s standard pull request interface and works with its existing reviews, automated checks and branch protection rules.
A pull request normally proposes moving changes from one branch into another. In a stack, the first branch targets the project’s main branch. The second targets the first, the third targets the second, and so on. Together they form an ordered chain.
Suppose a team is rebuilding a checkout page. The first pull request could reorganize shared data types. A second could replace the payment form. A third could add analytics. Reviewers can inspect those changes in focused pieces, even though the later work depends on the earlier layers.
GitHub adds a stack map to each pull request so reviewers can see what sits above and below the current layer. Crucially, the displayed difference is limited to that layer. Reviewers do not need to sift through the full accumulated change every time.
Developers can create stacks on GitHub’s website or use the new gh-stack command-line extension. GitHub also says the workflow is available through its mobile app and can be driven by coding agents. In the GitHub Copilot desktop app, one agent session can build on another and produce a corresponding series of pull requests.
Merging is where native support matters most. A team can merge the top ready layer together with every approved layer below it. It can also merge only the lower part of a stack. GitHub then rebases and retargets the remaining pull requests automatically, reducing the manual branch repair that often makes stacked work tedious.
The immediate audience is software teams handling migrations, broad product features and other changes that cannot sensibly fit into one small commit. The timing also reflects a newer problem. Coding agents can produce changes faster than people can understand them.
That does not make review optional. Generated code still has to fit the architecture, pass tests and behave correctly in production. If faster generation simply creates larger pull requests, the bottleneck moves from writing code to evaluating it.
Stacks offer a practical response because they constrain the unit of review. A database change can be discussed separately from the interface that depends on it. Security-sensitive logic can receive specialist attention without blocking review of unrelated presentation code. GitHub says early users including teams working on Next.js and TED have used this structure to make larger projects easier to inspect.
The useful angle is not that stacks make code automatically safer. They make the dependency structure legible. That can improve review only when each layer has a clear purpose, a manageable size and tests that match its scope.
Stacked pull requests are still a public preview and are rolling out over several days. Support for GitHub’s merge queue is arriving progressively over the following weeks. Teams should not assume every repository has the complete workflow yet.
There are also organizational costs. A stack can become harder to follow if its lower layers keep changing or if reviewers approve later work before understanding an unstable foundation. Ten tiny pull requests are not necessarily clearer than three coherent ones. The tool manages branch relationships, not editorial judgment about where one change should end and the next should begin.
Teams adopting the preview should start with work that already has natural boundaries. Dependency upgrades, schema preparation, feature logic and interface changes often separate cleanly. Each layer should build and test independently where possible, and its description should explain both its own purpose and what depends on it.
GitHub’s native implementation lowers the operational cost of this practice. Its real value will depend on whether teams use that convenience to produce smaller explanations, not merely more pull requests.