Weekly DevOps Roundup: Stacked PRs and Clearer PR Policies

by TechHub

This week's DevOps roundup focuses on keeping pull request review scalable as teams ship larger, AI-assisted changes. GitHub's stacked pull requests (public preview) introduce a practical way to split big diffs into reviewable layers across the UI, mobile, and the GitHub CLI, while new organization-level PR limits give maintainers a simpler way to manage contributor backlog. GitHub also adjusted Code Quality so it no longer auto-requests Copilot review, pushing teams to make automation and approval gates an explicit policy choice.

This Week's Overview

Code review workflow shifts in GitHub (stacked PRs, limits, and rulesets)

Building on last week's theme of tightening PR gates while pushing agent workflows earlier into the lifecycle, GitHub pushed harder on making large changes easier to review by putting stacked pull requests into public preview. Stacks let you split work into an ordered chain of smaller PR “layers”, and GitHub adds a stack map so reviewers can see dependencies and review in sequence instead of wading through one giant diff.

This is a practical response to the reality of AI-assisted coding, where teams often end up with oversized PRs that are hard to validate and easy to miss issues in. GitHub is positioning stacks as a first-class workflow across github.com, the GitHub mobile app, and the GitHub CLI, and it even shows up as a Copilot skill (gh-stack) so you can keep an agentic workflow without sacrificing review quality.

Stacked pull requests (public preview) and the gh-stack workflow

Stacked PRs are now usable from the browser UI and from the GitHub CLI via the gh-stack extension, with flows for creating, reviewing, rebasing/syncing, and merging an entire stack. In practice, this changes how you structure feature work: you can land early refactors, scaffolding, and tests first, then layer the behavior changes on top, which reduces review load and makes it easier to bisect regressions.

Several walkthroughs focus on how stacks interact with real repo constraints like CI requirements and branch protection, which fits neatly with last week's focus on more predictable merge-time checks as Code Quality and other rulesets become part of the default PR experience. If your CI or review policies require green checks per PR, stacked PRs give you a way to keep each layer small and independently verifiable, but you will still need discipline around rebasing and keeping dependent layers in sync as feedback comes in.

Org-level pull request limits for contributors without write access

GitHub organizations can now set pull request limits centrally, controlling how many open PRs a user without write access can have across all repos. This is a moderation and maintainability tool for orgs that receive lots of drive-by PRs (or have automation that opens PRs on behalf of external actors) and need to reduce backlog or abuse without turning off collaboration.

For maintainers, this shifts the control point from repo-by-repo settings to an org-wide policy, echoing last week's trend toward centralized, enforceable controls that keep contribution scalable without weakening review discipline. For contributors, it means the “open PR queue” can become a shared resource, so teams may want to document expectations (for example, keep PRs small, respond to feedback, and close stale PRs quickly).

GitHub Code Quality stops auto-assigning Copilot as reviewer

GitHub changed GitHub Code Quality so enabling it no longer auto-creates a ruleset that requests GitHub Copilot code review on pull requests. GitHub also disabled previously enabled auto-review settings in existing auto-created rulesets, which reduces the chance that Copilot gets silently added as a required or default reviewer when a team did not intend that.

This follows directly from last week's Code Quality GA discussion by tightening how quality gates get introduced, nudging teams to treat Copilot review as an explicit workflow choice rather than a side effect of turning on scanning. If you want Copilot review as part of your workflow, you now need to make that decision explicitly (for example, via your own rulesets or review automation). This should help teams avoid policy surprises, especially where compliance rules distinguish between automated checks and human approval.