GitHub’s general availability release means stacked pull requests are now a practical workflow option for teams using GitHub.com, not evidence that they will improve every product team’s delivery. Product leaders should assess whether splitting a larger change into smaller, connected reviews fits their approval model, release controls and available review capacity.

What has changed

GitHub describes stacked pull requests as smaller, focused pull requests that can be reviewed independently and merged together. Its general availability release adds behaviour intended to support review continuity and oversight, including preserved approvals for unchanged code after a stack rebase, signed replacement commits, merge-queue handling for a stack as a group, automatic retargeting and visible stack context. GitHub says the feature is available on all GitHub.com plans; inclusion in a future GitHub Enterprise Server release is planned.

Why this matters for product delivery

Large product changes can create a difficult trade-off: one broad pull request may give reviewers too much to absorb, while dividing work into unrelated changes can obscure the relationship between them. A stack offers a middle ground by making connected increments visible without treating them as wholly independent work.

For a business, the potential value is better decision-making around change rather than a guaranteed increase in engineering speed. Smaller review units may make it easier to identify dependencies, assign appropriate reviewers and understand the status of a larger initiative. That can be particularly relevant where product work spans interface changes, platform services and operational requirements.

Questions leaders should ask before changing working practices

  • Will smaller connected reviews make ownership and approval decisions clearer, or create extra coordination overhead?
  • Do existing release rules, required approvals and merge-queue policies reflect the risk of a whole connected change rather than a single component?
  • Can reviewers realistically assess individual changes while retaining enough context about the wider product outcome?
  • How will product, design and operations stakeholders know when a multi-part change is ready for release?
  • Which measures matter: review delays, rework, change risk, release predictability or another outcome relevant to the product roadmap?

Treat reported gains as evidence to test, not a forecast

GitHub reports that repositories using stacks during public preview saw a 9% increase in merged code compared with peers. It also reports that more than two-thirds of the top 1% of repositories used the feature and saw a 5% improvement in time-to-merge. These are vendor-reported comparisons, and the announcement does not provide methodology or establish that a similar outcome will occur for a particular organisation.

A proportionate decision

Stacked pull requests are most worth evaluating when larger changes regularly wait on review, when teams need clearer visibility of dependencies, or when broad pull requests make oversight difficult. They may be less compelling for small teams with simple changes and short review cycles. GitHub says auto-merge for stacks is rolling out over the following weeks, so teams considering that capability should distinguish current workflow decisions from features still being released.

OUROPT can help align product delivery practices, design and development work with the governance needs of a digital product roadmap.

Explore our services →

Sources and references

  1. Stacked pull requests generally availableGitHub Changelog · 6 October 2026