GitHub Stacked PRs Now Public: No Waitlist, No Rebase Hell

GitHub just dropped the waitlist. As of today, July 30, 2026, stacked pull requests are in public preview and available to any repository. Install one CLI extension and you’re in — no approval, no enterprise plan, no waiting. If rebase hell has been your constant companion, now is a good time to change that.

What GitHub Stacked PRs Actually Do

A stacked pull request targets another PR’s branch instead of main. You build a chain: branch A targets main, branch B targets branch A, branch C targets branch B. Each PR represents one logical layer of a larger change — database schema, then API, then UI. Reviewers see only the diff for their layer, with a stack map in the GitHub UI showing the full chain and one-click navigation between layers.

That stack map is the feature Graphite cannot match. It lives inside GitHub’s own PR interface, meaning reviewers need nothing installed — no Graphite account, no browser extension, no CLI. Context is there for everyone who opens the PR.

The data backs up why this matters. Research across 1.5 million pull requests shows PRs under 200 lines are reviewed three times faster and have 40 percent fewer production defects compared to larger PRs. Teams adopting stacked workflows report 42 percent faster review cycles overall. GitHub also notes 14 billion projected commits in 2026 versus roughly one billion in 2025 — AI coding agents are flooding review queues with massive diffs, and stacked PRs are the infrastructure response to that volume. Tim Neutkens from Next.js summed it up: “Helped us introduce smaller individual changes while shipping larger features, making it easier to review PRs.”

How to Enable GitHub Stacked PRs Right Now

Install the CLI extension and you have the full workflow available within minutes. The github/gh-stack extension is MIT-licensed and requires gh v2.0 or higher:

# Install the extension
gh extension install github/gh-stack

# Start a stack
gh stack init feature/db-schema       # first layer, targets main
gh stack add feature/api-routes        # second layer
gh stack add feature/ui-components     # third layer

# Push all branches and open PRs with correct base targets
gh stack push && gh stack submit

# After any review feedback changes a lower layer
gh stack sync    # cascades rebase up the entire chain

# Merge from bottom to top atomically
gh stack merge

Stack metadata is stored in .git/gh-stack as JSON and never committed to your repository. The CLI also integrates with git rerere automatically, so conflict resolutions are remembered across repeated rebases. You won’t resolve the same conflict twice.

Related: GitHub Stacked PRs Private Beta: Waitlist Required — ByteIota’s April 2026 coverage of the private preview launch

Does This Kill Graphite?

Not yet, but the pressure is real. Graphite’s founding premise was that GitHub’s native tooling for complex workflows was inadequate. GitHub just moved to address that directly. The native integration wins on one dimension that matters most: reviewers need zero setup. That removes the single biggest adoption barrier teams reported with third-party stacking tools.

However, Graphite has years of solved edge cases that GitHub v1 is still working through. The clearest example is squash-merge compatibility. When you squash-merge a PR, git rewrites the commit hash, which breaks the identity tracking that links branches in a stack. Graphite handles this cleanly after years of iteration. GitHub’s workaround is gh stack rebase after each squash merge — it works, but it adds a manual step. Additionally, merge queue support is still rolling out progressively and may not be available for your repository yet. Graphite also supports GitLab and Bitbucket; GitHub’s native tool does not.

The honest assessment: GitHub wins for teams where reviewer friction was the barrier. Graphite still wins for teams with established squash-merge workflows or multi-platform needs. For new teams deciding now, the free native integration with no per-seat cost is a strong default. As InfoWorld’s analysis put it, GitHub’s entry “validates the Stacking category but poses an existential threat to Graphite’s core value proposition.”

The One Setting to Check Before You Start

If your repository is configured to squash-merge or rebase-merge PRs by default, stack identity tracking will break after the first merge. The workaround is gh stack rebase, but the cleaner fix is switching affected repositories to merge commits for stacked workflows. Check under Settings > General > Pull Requests before you start. It takes thirty seconds and saves a confusing debugging session later.

Merge queue support is also still rolling out progressively. If your team relies on merge queues, verify that the feature is enabled for your specific repository before committing to the stacked workflow.

Key Takeaways

• GitHub stacked PRs are in public preview as of July 30, 2026 — enable with gh extension install github/gh-stack, no waitlist required.
• The stack map UI is built into GitHub’s own PR interface; reviewers need nothing extra installed.
• Keep each PR layer under 200 lines: sub-200-line PRs are reviewed 3x faster with 40% fewer production defects.
• If your repository squash-merges by default, switch to merge commits or run gh stack rebase after each merge — otherwise stack tracking breaks.
• Graphite is not dead, but its core differentiator just got smaller. The free, native option is now good enough for most teams.