{
  "id": 79942,
  "title": "GitHub Brings Stacked Pull Requests Out of the Shadows",
  "url": "https://urgent.news/2026/08/03/github-brings-stacked-pull-requests-out-of-the-shadows",
  "topic": "culture",
  "section": "Culture",
  "published": "2026-08-03T10:19:27.000Z",
  "source": {
    "name": "DevOps.com",
    "slug": "devops-com",
    "url": "https://devops.com/github-brings-stacked-pull-requests-out-of-the-shadows/"
  },
  "original_language": "en",
  "account": "For over a decade, large software organizations such as Meta and Google have quietly embraced a practice known as stacked pull requests. This workflow involves dividing a single feature into an ordered sequence of smaller pull requests, each of which builds upon the previous one. Open source developers have copied this approach using tools like ghstack, but GitHub has now made it a native feature. The company announced that stacked pull requests are in public preview, available to all repositories in the coming days.\n\nThe concept of stacking is straightforward, yet its implementation requires a shift in mindset. Instead of creating one massive pull request that encompasses the entirety of a feature, developers break the work into incremental, ordered layers. Each layer is represented as a separate pull request, stacking on top of the last. For instance, a schema update might serve as the foundation, with subsequent layers adding business logic and UI changes.\n\nReviewers benefit significantly from this approach. Instead of sifting through a single, convoluted diff spanning thousands of lines, they can examine each layer independently, gaining clarity on the specific change without being overwhelmed. Extensive research on code review patterns has consistently demonstrated that review quality decreases as pull requests grow in size. One study analyzed 1.5 million pull requests and found that smaller changes, under 200 lines, were approved roughly three times faster and contained 40% fewer defects than larger ones. As pull requests exceed 1,000 lines, the likelihood of identifying real issues plummets.\n\nThe rationale behind this decline in review quality is simple: reviewers simply exhaust their mental bandwidth attempting to scrutinize increasingly complex changes. Mitch Ashley, VP and practice lead for software lifecycle engineering at The Futurum Group, emphasized that \"review capacity sets delivery pace on most teams.\" By breaking a change into ordered layers, reviewers can verify the schema before evaluating the logic built upon it.\n\nGitHub's implementation of stacked pull requests leverages a new command-line interface (CLI) extension called gh-stack, along with support on github.com and the GitHub mobile app. Additionally, the feature integrates with coding agents like GitHub Copilot, which uses a dedicated skill to facilitate the process. Developers initiate the workflow by creating a branch and initial pull request for their first change, then add subsequent branches and pull requests, each targeting the layer beneath it. A visual \"stack map\" displayed at the top of each pull request illustrates how that particular layer fits into the larger change, providing reviewers with necessary context without the need to review the entire stack at once.\n\nThe merge process is where GitHub's approach truly shines. Merging the latest ready pull request in a stack lands that change, along with all unmerged layers beneath it, as a single operation. Teams can also merge partial stacks, allowing lower layers to be landed while the remaining PRs remain open. These new layers are automatically rebased and retargeted against the updated base. Crucially, existing branch protections, required checks, and merge queues continue to apply throughout the process, as stacking is seamlessly integrated into GitHub rather than added as a separate tool.\n\nEarly adopters have reported notable improvements in their workflows. Vercel's Next.js team highlighted how stacked pull requests enabled them to deliver larger features while maintaining smaller, more manageable changes that were easier to review. Similarly, TED's engineering team found that stacking addressed the challenge posed by AI coding tools, which have generated increasingly large pull requests that overwhelmed reviewers. By breaking down agent-generated work into dependency-ordered chunks, teams could verify the foundation before proceeding to more complex changes. This approach not only speeds up the review process but also enhances accuracy.\n\nHowever, the benefits of stacked pull requests are contingent upon the presence of a genuine dependency chain. Stacking unrelated changes, simply because multiple AI agents produced them in parallel, introduces unnecessary complexity without yielding tangible benefits. As Mitch Ashley pointed out, \"Verification debt is what makes small changes worth the extra branches.\" Teams that measure productivity by merged volume may find themselves compelled to hire more reviewers to keep up with the speed of AI-generated code. Engineering leaders must instead size work in a way that aligns with what reviewers can effectively manage.\n\nGitHub's integration of stacked pull requests into its platform signals a strategic move to address the challenges posed by large pull requests from a systemic perspective, rather than merely offering a workflow preference. As AI tools continue to accelerate code generation, the manner in which code is reviewed may come to hold even greater significance than the code itself.",
  "summary": "GitHub introduces native stacked pull requests, helping development teams break large changes into smaller, dependency-ordered PRs that are faster and easier to review.",
  "key_points": [
    "GitHub introduces stacked pull requests as native feature",
    "Enables developers to break features into ordered layers",
    "Reviewers benefit from clearer, smaller changes"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}