GitHub Stacked Pull Requests Public Preview

GitHub introduces Stacked Pull Requests to solve the "Giant PR" problem

GitHub has launched a public preview of Stacked Pull Requests, a feature designed to decompose large, complex changes into a sequence of smaller, focused pull requests (PRs). Instead of a single massive PR that is difficult to review and slow to merge, developers can now create an ordered series of "layers," where each PR targets the one immediately preceding it in the stack.

This workflow allows teams to maintain high velocity by reviewing short, narrowly scoped changes in parallel while ensuring that the final set of changes is landed as a cohesive unit. According to Tim Neutkens, NextJS lead at Vercel, the feature has already helped their team "introduce smaller individual changes while shipping larger features, making it easier to review PRs."

Core Functionality and Workflow

Stacked PRs enable a more granular approach to feature development and review. The system integrates directly with GitHub's existing infrastructure, meaning branch protections, required checks, and review requirements remain active for every layer of the stack.

Creating and Managing Stacks

Developers can create stacks using several interfaces:

  • GitHub CLI: The primary tool for managing stacks, accessible via the gh extension install github/gh-stack command.
  • GitHub.com: Web-based creation and management.
  • GitHub Mobile: Support for managing stacks on the go.
  • AI Agents: Integration with coding agents like GitHub Copilot using the gh-stack skill.

Independent Review and Parallelism

Each PR in a stack can be reviewed independently. Reviewers can use a "stack map" at the top of the PR to visualize how the current layer fits into the overall sequence of changes. This prevents the "bottleneck" effect where a single large PR blocks an entire feature; instead, teammates can review different layers of the stack simultaneously without blocking further development.

Flexible Merging Options

GitHub provides three primary ways to land changes from a stack:

  1. Merge All: Merge the latest ready PR to land it and every unmerged layer below it in a single operation.
  2. Merge Some: Land a subset of the stack by merging lower layers first.
  3. Merge One: Land individual layers one at a time.

When lower layers are merged, the PRs above them in the stack automatically rebase and retarget to the new base branch.

Technical Implementation and Tooling

To get started, users must install the official CLI extension:

gh extension install github/gh-stack

The gh stack rebase command is highlighted as a critical tool for keeping local branches in sync with the remote stack, though some users have noted that its effectiveness depends on local branches being properly synchronized with the remote.

Community Feedback and Critical Perspectives

While the announcement has been met with excitement by some, the Hacker News community has raised several technical and workflow concerns regarding the public preview.

Reported Technical Issues

Some early adopters have reported stability issues with the preview. User @matharmin noted that "merging an entire stack is completely broken in many cases," and highlighted a friction point where squash-merging requires re-approval for every PR in the stack if reviews are required, potentially negating the efficiency gains of the one-click merge.

Workflow Debates: Stacking vs. Atomic Commits

There is a significant debate among senior developers regarding whether stacking PRs is a fundamental improvement or simply a UI wrapper for existing Git behavior.

  • The "UI Wrapper" Argument: Some users, such as @ankit84 and @dysoco, argue that stacking is simply a formalization of creating branch B from branch A and pointing PR B to branch A—a workflow that has always been possible in Git.
  • The "Atomic Commit" Argument: Others, including @rrradical and @beaker52, suggest that the same goal of reviewability can be achieved through a well-curated set of atomic commits within a single PR, which reviewers can then navigate commit-by-commit.
  • The "Productivity" Argument: Proponents, including @paxys and @tao_oat, argue that native support removes the immense friction of manual rebasing and provides a better UX than third-party tools like Graphite, making the workflow more accessible to a broader range of developers.

Feature Requests and Limitations

Users have identified several gaps in the current implementation:

  • Cross-Repository Stacks: The current system is limited to a single repository. Users have requested the ability to stack PRs across different repos (e.g., backend, frontend, and infrastructure).
  • Non-Linear Stacks: Current stacks are linear. Users have requested "trees" of PRs to support dependent changes that do not follow a straight line.
  • Metrics: There is uncertainty regarding how stacked PRs affect developer experience (Dx) metrics—specifically, whether a merged stack of three PRs counts as one or three in productivity tracking.

Sources