What is a Merge Queue?

A merge queue sits between “PR approved” and “PR merged.” It validates changes before they land on main.

Simple merge queues serialize merges. Modern ones do more: test PRs against future main state, batch PRs together, run dedicated CI, and parallelize testing across independent code paths.

The Core Problem

Without a merge queue, two PRs can each pass CI individually, yet break main when combined. Each PR is tested against an outdated snapshot of main—not against each other.

This happens constantly: renamed modules, deleted functions, changed signatures, conflicting config changes. No merge conflict, but broken code.

Want the full breakdown?

See What Happens Without a Merge Queue for detailed failure scenarios and their cascading costs.

The Paradigm Shift: CI Before Merge, Not After

A merge queue tests each PR against its actual merge target—including all PRs ahead of it. The key insight: test the PR against what main will look like after the merge, not what it looked like when the PR was created.

Traditional workflows run final CI after merging to main:

The problem: by the time you discover the failure, main is already broken. The damage cascades:

1. Deployments stop - you can’t ship until main is fixed
2. All developers are blocked - no one can merge until the fix lands
3. New PRs inherit the breakage - any PR based on broken main will also fail CI
4. Everyone must rebase - after the fix, every in-flight PR needs to rebase
5. The cycle can repeat - rebasing and re-merging might break main again

A merge queue flips this: final CI runs before the merge:

The queue tests the PR as if it were already merged with current main. Pass? Merge succeeds. Fail? PR rejected, main untouched.

This means:

• Main stays green — broken code never lands
• Deploy anytime — main is always releasable
• Failures stay contained — only the PR author fixes their code

A merge queue makes “broken main” impossible by construction.

Core Capabilities

Modern merge queues offer more than serialization:

• Two-Step CI — Separate PR validation from queue validation
• Batching — Test multiple PRs together
• Speculative Checks — Parallelize testing by assuming success
• Parallel Queues — Independent queues for non-conflicting changes
• Freshness Policies — Balance safety and throughput
• Priority Management — Let urgent PRs jump the queue
• Affected Targets — Test only what changed

Summary

A merge queue does more than automate merges. It:

1. Keeps main stable by testing PRs against their actual merge target
2. Validates before merging — CI runs before code lands, not after
3. Increases throughput through batching, speculation, and parallelism
4. Scales to large codebases with selective testing
5. Handles exceptions with priority queues

Next: How merge queues work covers the mechanics.