Skip to main content

GitHub Introduces Stacked PRs to Ease Review Bottlenecks

GitHub’s new Stacked Pull Requests feature restructures how developers submit and review changes by allowing large code updates to be broken into smaller, interdependent units.

With Stacked PRs, each unit can be reviewed and merged individually while still contributing to the overall feature set. The approach helps developers shift away from monolithic pull requests, which have become increasingly difficult to manage as development continues to move faster.

The release of Stacked PRs is a response to the rise of AI-assisted coding tools, which have greatly increased the volume and scale of code submissions, placing new pressure on review workflows. While large pull requests spanning dozens of files used to be merely inconvenient, they are sometimes now a systemic issue. There is a widening gap between code generation and code review, with reviewers dealing with reduced visibility and slower turnaround times.

With the layered workflow of Stacked PRs, developers can sequence related changes so that each pull request builds on the previous one. Reviewers, in turn, assess smaller, focused diffs while maintaining visibility into how each piece contributes to the overall change. The structure allows teams to merge either individual components or entire stacks, depending on readiness.

Building on Earlier Solutions

Similar workflows, often described as “stacked diffs,” were popularized in earlier code review systems. These systems addressed the same issues around reducing wait times for reviews while preserving development momentum. GitHub’s move brings this model into its native platform, reducing the need for third-party tools that previously filled the gap.

This offers big advantages, particularly for companies managing large codebases and monorepos. In these environments, development can be modular, with teams working on interconnected components in parallel. Traditional pull request models often forced developers to choose between waiting for upstream changes to merge or bundling work into large, unwieldy submissions. Stacking introduces a middle path, enabling incremental progress without sacrificing structure.

GitHub has paired the feature with a command-line extension that automates much of the underlying workflow, including branch management and rebasing. On the interface side, stacked changes are presented visually, allowing reviewers to navigate the hierarchy of updates and understand dependencies between them. This integration of CLI and UI is intended to lower the barrier to adoption.

Cultural Shift

The technical implementation of Stacked PRs may prove easier than the cultural shift required to use it effectively. Developers must reorganize how they structure their work, breaking features into logically discrete units that can stand on their own. This could be a challenge for teams accustomed to broader, less segmented workflows.

This release will likely cause some competitive disruption. By embedding stacked workflows directly into its platform, GitHub is encroaching on tools that built their value around this capability. Vendors that previously offered stacking as an extension to GitHub must now differentiate beyond core functionality.

More broadly, the feature is a recalibration of development priorities. As AI systems speed up code production, the limiting factor is no longer writing software but validating it. Review workflows, once secondary, are becoming central to maintaining quality and stability.



from DevOps.com https://ift.tt/4viJyNG
Labels:

Comments

Post a Comment

Popular posts from this blog

Claude Code’s Ultraplan Bridges the Gap Between Planning and Execution

Planning a complex code change is hard enough. Reviewing it in a terminal window shouldn’t make it harder. Anthropic is addressing that friction with a new capability called Ultraplan, currently in research preview as part of Claude Code. The feature moves the planning phase of a coding task from your local terminal to the cloud — and gives developers a richer environment to review, revise, and approve a plan before a single line of code changes. It’s a small workflow shift with real practical value, especially for teams working on large-scale migrations, service refactoring, or anything that requires careful coordination before execution begins. How it Works Ultraplan connects Claude Code’s command-line interface (CLI) to a cloud-based session running in plan mode. When a developer triggers it — either by running /ultraplan followed by a prompt, typing the word “ultraplan” anywhere in a standard prompt, or choosing to refine an existing local plan in the cloud — Claude picks u...
Post a Comment
Read more

Java 26 Arrives With AI Integration and a New Ecosystem Portfolio — What It Means for DevOps Teams

Oracle released Java 26 on March 17, 2026, and while every six-month release comes with its own set of improvements, this one carries a broader message: Java isn’t just keeping pace with the AI era — it’s actively positioning itself as the infrastructure layer where AI workloads will run. For DevOps teams managing large Java estates, that’s worth paying attention to. The Scale of What You’re Already Running Before getting into what’s new, it helps to remember what’s already in place. According to a 2025 VDC study, Java is the number one language for overall enterprise use and for cloud-native deployments. There are 73 billion active JVMs running today, with 51 billion of those in the cloud. That scale matters when you’re thinking about where AI fits in. Most of the systems where agentic AI will eventually operate — transactional platforms, backend services, data pipelines — are already running on Java. The question for DevOps teams isn’t whether to adopt Java for AI. It’s how to ...
Post a Comment
Read more

Security as Code is Becoming the New Baseline: Continuous Compliance in DevOps 

There was a time when compliance meant a quarterly ritual. Someone from security would walk over with a spreadsheet, ask a few questions, tick a few boxes and disappear until the next audit cycle. The infrastructure team would scramble to prove that yes, encryption was enabled, and no, that S3 bucket was not public anymore. Everyone felt relieved, went back to shipping features and quietly hoped nothing would drift before the next review.   That model is dead; it just hasn’t been buried yet.   The problem is not that teams lack security awareness. Most engineering organizations today understand that vulnerabilities need catching early and that production environments need hardening. The problem is that compliance has historically lived outside the delivery pipeline — treated as a checkpoint rather than a continuous practice. In a world where teams deploy dozens of...
Post a Comment
Read more