DevOps / SRE / Platform · 03.08.2026, 11:18 UTC
GitHub Brings Stacked Pull Requests Out of the Shadows
| Schweregrad | info |
|---|---|
| Kategorie | DevOps / SRE / Platform |
| Quelle | DevOps.com ↗ |
| Veröffentlicht | 03.08.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
For years, stacked pull requests have been something of an open secret in software engineering. Teams at Meta and Google have used internal versions of the workflow for over a decade, and open source developers cobbled together their own approach with tools like ghstack. Now GitHub is making it a native feature. The company announced this week that stacked pull requests are in public preview, rolling out to all repositories over the coming days. The idea behind stacking is simple, even if the mechanics take some getting used to. Instead of building one large pull request that captures an entire feature, developers break the work into an ordered series of smaller PRs. Each one sits on top of the last, representing a single layer of the change. A schema update might be the base layer, with business logic stacked on top of that, and a UI change stacked on top of that. Reviewers can look at each layer on its own, without wading through a diff that spans a thousand lines. That distinction matters more than it might seem. Research on code review patterns has consistently found that review quality drops as pull requests grow. One analysis of 1.5 million pull requests found that changes under 200 lines get approved roughly three times faster than larger ones, and carry about 40% fewer defects. Every additional 100 lines adds close to 25 minutes of review time, and once a PR passes the 1,000-line mark, the odds of catching real problems fall sharply. Reviewers simply run out of the mental bandwidth needed to do the job well. “Review capacity sets delivery pace on most teams,” said …