Netlify Now Previews Every PR in a GitHub Stack, Not Just the First

Netlify now creates a Deploy Preview for every pull request in a GitHub stack, not just the first one, closing a gap that had made stacked PRs a worse fit for Netlify than a single, unstacked branch (Netlify changelog, Aug 27, 2026).

---

What changed

A stacked pull request splits one large change into a chain of smaller PRs, each building on the one below it, so a reviewer can approve and merge them in sequence instead of wading through a single sprawling diff. Netlify’s Deploy Previews used to only cover the bottom PR in that chain, the one that would eventually land on the production branch. Every PR stacked on top of it shipped without a live preview, which meant a reviewer on layer three of a five-layer stack had no running build to click through, just a diff.

The fix is automatic: any stack that ultimately targets the project’s production branch now gets a Deploy Preview attached to each pull request in it, with nothing to configure (Netlify changelog, Aug 27, 2026).

Why it matters

Netlify’s fix lands a month after GitHub pushed native stacked pull requests into public preview for every repository on July 30, 2026, installed via the gh-stack CLI extension and rolling out with merge queue support to follow (GitHub Changelog, Jul 30, 2026). That move put pressure on Graphite and Aviator, startups built around giving teams a stacked-diff workflow GitHub itself didn’t offer.

The launch split developer opinion. A Hacker News thread on GitHub’s rollout drew 516 points and 282 comments, ranging from developers glad to see ‘stacked diffs… glad GitHub is joining 2016’ to skeptics who argued that dependent PRs reviewed in isolation ‘makes no sense,’ pointing at squash-merge compatibility and cascading rebase conflicts as the harder problems Graphite has spent years solving (Hacker News discussion). Whichever side is right about the workflow itself, every team that tries it on GitHub is also a Netlify customer’s problem the moment they open pull request two: no preview, no way to sanity-check the layer before approving it.

The take

GitHub set the workflow’s terms here, and Netlify spent a month catching its own tooling up to match. That’s the right order of operations for a deploy platform: it doesn’t need an opinion on whether stacked PRs are worth the rebase overhead, only on making sure a team that adopts them isn’t worse off on Netlify than they’d be with a single branch. The more interesting data point is the month-long gap itself. It suggests Netlify wasn’t tracking the feature closely until customers started stacking PRs against it.