Is GitHub Taking the Right Bet With Stacked Pull Requests?

GitHub has unveiled native Stacked Pull Requests, bringing one of the platform’s longest-requested developer workflows into the product after years of relying on third-party tools. 

The public preview introduces first-party support for breaking large code changes into an ordered series of smaller, dependent pull requests that can be reviewed independently, tested in parallel, and merged individually or together in a single operation. 

Built directly into GitHub, the workflow preserves existing branch protections, review requirements, and CI checks. Further, it eliminates much of the manual branch management and rebasing that developers previously relied on third-party tools to handle.

The feature marks GitHub’s first native implementation of a workflow that has long existed outside the platform. 

In March, then GitHub executive Jared Palmer revealed that the company was circulating an early proposal for ‘Stacked Diffs’ among a small group of design partners to gather feedback. The workflow entered private preview in April before expanding to an alpha programme, eventually reaching public preview this week.

A Workflow GitHub Took 18 Years to Ship

Previously, GitHub developers depended on tools including Graphite, Sapling, and ghstack to manage dependent pull requests.

Rather than asking reviewers to inspect a single sprawling pull request containing thousands of lines of code, stacked PRs split a feature into logical layers—such as a refactor, backend API, and frontend implementation. Each layer can be reviewed independently while remaining part of a larger feature, allowing developers to continue building higher layers before earlier changes have been approved.

GitHub may have brought stacked pull requests into the platform, but it is entering a space shaped by developer tools for years. 

Since its launch in 2020, Graphite has built its entire workflow around stacked pull requests, arguing that breaking large code changes into smaller, dependency-aware reviews helps engineering teams ship faster and stay unblocked. The platform automates rebasing, stack visualisation, and merge sequencing while integrating directly with GitHub, positioning itself as a dedicated code review workflow rather than just another Git client. 

Graphite is not alone. Meta’s Phabricator popularised stacked reviews internally before inspiring tools such as Sapling, while a growing ecosystem of utilities including Git Town and Git-Spice emerged to simplify managing dependent branches outside GitHub. 

Rather than inventing the workflow, GitHub’s announcement effectively standardises it for the platform's hundreds of millions of users by making stacks a first-class part of the pull request model instead of something managed through external tooling. 

The launch was met with enthusiasm across developer communities. On Reddit, developers called the release ‘long overdue’, arguing that GitHub’s implementation finally removes the need for third-party tooling for a workflow many teams have relied on for years.

In a post on X, Oskar Kwaśniewski, Co-founder and CTO of YC-backed TesterArmy, argued that GitHub’s challenge was never implementing stacked branches—Git had always supported those—but redefining what a pull request means across a platform built around the assumption that every pull request has a single base branch, one set of review rules, and one merge operation.

According to Kwaśniewski, GitHub’s implementation turns a collection of related pull requests into a first-class platform object, enabling cascading rebases, consistent application of branch protection rules, CI checks, and CODEOWNERS across every layer, while exposing stack metadata through its APIs.

Is GitHub Solving the Wrong Problem?

However, not everyone believes stacked pull requests are the future of code review.

Tuomas Artman, Co-founder and CTO of project management platform Linear and former Meta engineering leader, argued that stacked PRs solve a symptom rather than the underlying issue. 

In a post on X, he described them as ‘an outdated, inefficient solution’. He believes stacked PRs only exists “because the root problem hasn’t been addressed in GitHub: review tools need to do a better job at helping the reviewer work through large code changes.” 

Similarly, developers on Reddit argued that Git already provides commits as a natural way to break large changes into smaller, logical units, questioning whether GitHub was introducing a new abstraction to compensate for limitations in its own pull request interface rather than improving commit-based code review. 

The launch also comes at a time when the company has faced mounting criticism over outages, pricing changes, and an increasingly AI-centric product strategy.

Others argued that stacked pull requests solve a social rather than a technical problem.

“Most of Big Tech solutions often feel like they’re accounting for overly toxic workflows,” said one developer on Reddit. 

They suggested the workflow exists largely because teams have to coordinate dependent work across multiple developers and review cycles, raising the question of whether better planning, not better tooling, is the real solution.

AI Has Changed the Bottleneck

While some developers argued that GitHub should improve commit-level reviews instead of introducing another abstraction, others said the distinction becomes more important in the AI era.

Commits record how software is built; they argued, while pull requests represent logical, reviewable units of work. 

As AI accelerates code generation, stacked pull requests help ensure review and deployment can keep pace by allowing teams to approve independent pieces of functionality without blocking an entire feature.

Many developers on HackerNews described stacked pull requests as one of GitHub’s biggest workflow improvements in years, arguing that native support could expose a much broader audience to review practices previously associated with systems such as Gerrit, Phabricator and Graphite. 

“Hopefully this can make the stacked PR workflow more common and give people an easier alternative to mammoth PRs,” wrote one user after using Graphite, welcoming GitHub's native implementation. 

“It's been over four years since I’ve been out of Facebook and now have to use GitHub, and to this day I miss Phabricator and landing stacked changes,” wrote one developer on Hacker News. 

They added that they hadn’t realised that this was a ‘very basic workflow’ that GitHub lacked.

GitHub Acknowledges Early Bugs and Complaints

However, early preview users also highlighted shortcomings. 

“Merging an entire stack is completely broken in many cases,” one developer wrote on Hacker News, pointing to issues with squash merging that often required repeated review approvals after rebases. 

Others also called for features such as cross-fork stacks and richer review interfaces. 

GitHub also responded directly to criticism in the discussion. “We’re rolling out a series of bug fixes” for stack merging, wrote GitHub’s Senior Product Manager Sameen Karim on Hacker News. 

He explained that squash-merging stacked pull requests posed complex technical challenges because GitHub must preserve merge rules and review approvals across rewritten commit histories, while noting that 99% of stack merges already complete successfully. 

Karim said resolving the remaining issues was “the top priority for the team,” highlighted new public APIs for stack operations and atomic merges to reduce repeated CI runs. 

He also confirmed that cross-fork support was coming, though multi-fork stacks remain unlikely because of security concerns, and added that GitHub was “working on a much broader revamp for the PR UI” with improved stack navigation and visibility.