Smaller pull requests, faster releases: what GitHub stacked pull requests change

Stacked pull requests are now generally available on GitHub. Announced on 6 October 2026, the feature lets a team break a large change into smaller, focused pull requests that are reviewed independently and merged together. GitHub reports that repositories using stacks saw 9% more merged code than their peers during the preview.

If you run a software product, this matters for one simple reason: big changes are where releases slow down. This article explains what GitHub announced, how stacks work, and the review habits we use to ship features to clients every week.

What GitHub announced

• 9% more merged code in repositories using stacks, compared to peers, since the feature entered public preview.
• Over two-thirds of the top 1% of repositories now use stacked pull requests, and have seen a 5% improvement in time-to-merge.
• Auto-merge for stacks is rolling out over the next few weeks, so a whole stack can merge once the repository’s requirements are met.

How stacked pull requests work

1. 1Split the change. A large feature becomes several small pull requests, each building on the one before it.
2. 2Review each part. Reviewers look at one focused change at a time instead of one huge diff.
3. 3Keep approvals. When an unchanged stack is rebased after the main branch moves ahead, approvals are now preserved, and rebased commits stay signed.
4. 4Merge together. The stack enters the merge queue as a single merge group. If the stack’s base branch is deleted, GitHub retargets it automatically.

For developers who work from the terminal or with AI coding agents, the gh stack extension for GitHub CLI now supports Git worktrees.

Why smaller changes ship faster

In our experience, most delays in a software project are not in writing code. They are in waiting: for review, for testing, for someone to feel confident enough to release. Large changes wait the longest, because nobody can check a thousand-line change quickly or safely.

Small, focused changes reverse that. They are easier to review, easier to test, and easier to roll back if something goes wrong. Stacked pull requests make this practical even for big features, because the work can be split without losing the connection between the parts.

Habits for faster releases

These are the habits we recommend, based on our project experience. They work with or without stacks:

1. 1Keep each change small enough to review in one sitting.
2. 2One purpose per pull request. A bug fix and a new feature should not travel together.
3. 3Automated tests on every change, run by your CI pipeline, so reviewers focus on logic rather than basics. Our article on GitHub Actions changes covers keeping that pipeline healthy.
4. 4Review within one working day, so changes do not pile up.
5. 5Ship behind feature flags when a feature needs several releases to complete.
6. 6Demo progress every week, so the people paying for the product see it take shape.

What it means for your business

You do not need to know what a pull request is to benefit from this. What you will notice is the rhythm: a team that works in small, reviewed steps can show you something new every week, and fix problems quickly when they appear. We suggest asking any development partner how they review and release changes, not just how fast they write code.

If you are planning a new product, our MVP development guide explains how to start small and grow from real feedback.

How Estontinc helps

Estontinc is a software house in Malang with 100+ projects and 50+ clients over more than six years. Through our web development and custom software services, we build in small, reviewed steps, run automated tests on every change, and show you progress in weekly demos.

The source code is yours, and fixed-price projects include 30 days of free support after launch. Tell us about your product through the contact page and we will reply within 24 hours.