What Is a Merge Queue? How It Stops Broken Main Branches

What is a merge queue?

A merge queue is an automation that serializes the merging of approved pull requests, re-running CI against the up-to-date main branch before each merge so that individually-green PRs cannot combine into a broken build. It sits between “approved” and “merged,” acting as the final gatekeeper for your default branch.

The problem it solves is subtle and expensive. In a busy repository, several developers get their pull requests reviewed and approved throughout the day. Each PR passed CI when it was opened. But CI ran against the version of main that existed at that moment - not the version that exists after the three PRs ahead of it merged. When everyone clicks merge, the branch can break in ways no single PR predicted. A merge queue removes that gap.

Merge skew - the bug that green checkmarks hide

The specific failure mode a merge queue prevents is called merge skew, or a semantic merge conflict. It is not the same as a git merge conflict.

Consider two pull requests:

• PR A renames the function getUser() to fetchUser() and updates every caller it knows about.
• PR B, opened in parallel, adds a new file that calls getUser().

Git sees no textual conflict - the two PRs touch different files. Each passes CI against main independently. But the moment both merge, main references a function that no longer exists, and the build breaks. No reviewer did anything wrong. The tooling simply never tested the combined state.

This happens constantly at scale: a shared type changes in one PR while another PR adds a usage of the old shape, a config key is removed while another PR reads it, a database migration reorders columns while another query assumes the old order. The takeaway: green checkmarks on two separate PRs do not prove that main will be green after both land. Only testing the combined result proves that.

How a merge queue works

Once a PR is approved and added to the queue, the queue takes over:

1. Form a candidate. The queue creates a temporary branch containing main plus the PR being tested plus every PR already ahead of it in the queue.
2. Run CI on the candidate. This is the crucial difference - CI runs against the exact state the PR will merge into, not a stale snapshot.
3. Merge on green, eject on red. If CI passes, the PR merges to main. If it fails, the queue removes the offending PR and re-tests the rest, so one bad change does not block everyone behind it.
4. Repeat. The queue processes the next candidate.

Advanced queues optimize this with batching and speculative execution: they test several queued PRs together in parallel, assuming they will all pass, and only fall back to testing individually when a batch fails. This keeps throughput high without sacrificing correctness. Flaky-test protection is another common feature - the queue can automatically retry a known-flaky job rather than ejecting a good PR because a test failed for unrelated reasons.

Merge queue vs “require branches to be up to date”

GitHub has long offered a branch protection rule that requires a branch to be up to date with main before merging. Is that not the same thing?

Not quite. The “require up to date” rule forces each author to rebase or merge main into their branch and wait for CI again - manually, one at a time. In a busy repo this creates a race: by the time your rebased branch goes green, someone else has merged, and you must rebase again. Developers can spend an afternoon chasing a moving target.

A merge queue automates exactly this dance. Authors add their PR to the queue and walk away; the queue handles the rebasing, re-testing, and ordering. The rule of thumb: “require up to date” is fine for low PR volume; a merge queue is what you reach for when the manual rebase race starts wasting real engineering hours.

Which platforms offer a merge queue in 2026

Merge queues used to be bespoke infrastructure built by large companies. Now they are available off the shelf.

GitHub merge queue is built into GitHub for repositories on the appropriate plans. You enable it in branch protection settings, and it handles candidate creation, batching, and merging natively. For teams already standardized on GitHub Actions, it is the lowest-friction option because there is nothing extra to install.

Graphite offers a stack-aware merge queue as part of its developer productivity platform, available on its Team plan at $40 per user per month. Its differentiator is that the queue understands stacked pull requests: instead of running CI on each PR in a dependent chain separately, it validates the whole stack as a unit by running CI on the top-most PR, which already contains all downstream changes, and merges atomically. Graphite reports that this batching cut redundant CI runs enough that Shopify projected 15 to 25 percent CI cost savings across its organization. Graphite is GitHub-only.

Mergify is a dedicated merge automation service that provides a merge queue with batching and configurable rules, and works across GitHub. It is a good fit for teams that want a queue plus broader merge automation without adopting a full workflow platform.

Note that a merge queue governs when code lands, not whether it is any good. It pairs naturally with an AI reviewer like CodeRabbit that gives feedback while the PR is still open, so that by the time a change reaches the queue, the substantive issues are already resolved. See our overview of what AI code review is for where that fits.

Is a merge queue right for your team?

A merge queue earns its keep when three conditions line up:

• High PR volume. Many PRs land per day, so the odds of two interacting badly are real.
• Slow-ish CI. If CI takes 15 minutes and five PRs merge per hour, branches go stale before they can merge manually.
• A protected main branch. Your team treats a broken main as an incident, not a shrug.

If your team merges a handful of PRs a day with two-minute CI, a merge queue is overhead you do not need - the “require up to date” rule and small, fast PRs will serve you better. Keeping PRs small is worth doing regardless, because it shrinks the surface for merge skew in the first place; see our guide on pull request size best practices.

Conclusion

A merge queue is the automation that makes a “never break main” policy actually enforceable at scale. It closes the merge-skew gap that green checkmarks quietly hide, automates the rebase race that otherwise burns engineering time, and, in its stack-aware form, eliminates redundant CI on chains of dependent PRs. GitHub, Graphite, and Mergify all offer production-ready queues in 2026. Reach for one when PR volume, CI duration, and a strict main-branch policy make manual merging a bottleneck - and pair it with small PRs and early AI review so the queue only ever sees changes that are already good.

Further reading

• What Are Stacked Diffs? Faster Reviews with Stacked PRs
• Pull Request Size Best Practices - The Case for Small PRs
• What Is AI Code Review? How It Works and Benefits
• Stacked PRs - glossary definition