A merge queue is CI’s answer to a sneaky failure: two pull requests, each green against main, that break when combined. One renames a function; the other adds a new call to the old name. Both pass, both merge, main is red. The queue fixes this by testing each PR against main plus everything already queued, so “green” means “green against what main will actually be.”
GitHub, GitLab and Bors all offer one. The question is not whether they work - they do - but whether your team has the problem they solve.
The threshold#
The broken-main-from-colliding-PRs problem needs two ingredients: enough parallel merges that collisions are likely, and a test suite slow enough that “just rebase and rerun CI” is painful. A team merging three pull requests a day with a five-minute suite almost never sees it. A team merging thirty a day with a forty-minute suite sees it weekly.
Some honest signals you have crossed the line:
- Main breaks from semantic conflicts more than once a month, and each break costs real debugging time.
- Reviewers ask authors to “rebase and make sure it is still green” so often that the rebase-rerun loop is the bottleneck.
- Releases get delayed because main went red at the wrong moment.
What to do before you get there#
Most small teams get the same protection cheaper:
- Keep CI fast. A five-minute suite makes “rebase and rerun” a shrug, not an afternoon. This is the same investment as always - shallow clones and dependency caching - and it pays whether or not you ever need a queue.
- Require branches to be up to date before merging on the riskiest repo. GitHub’s branch protection has this checkbox; it forces the rebase-rerun loop explicitly, which is exactly a manual merge queue. Fine at low volume, painful at high volume - which is your signal.
- Merge promptly after approval. Most collisions happen because approved PRs sit for days while main moves on. A queue will not fix a review-and-forget habit; small pull requests will.
When the manual loop becomes the thing slowing everyone down, the queue stops being infrastructure cosplay and starts paying rent. Until then, the honest answer is: not yet - and here is how you will know.
Share this post
Keep reading
A First CI Pipeline for a Laravel Project
Install, lint, test, build - four jobs that run on every pull request and turn 'works on my machine' into a check everyone can see.
A Staging Environment Worth Having
Staging only catches what it shares with production. Same deploy path, same services, sanitized data - and a clear rule for what it is for.
Branch Naming Conventions That Scale Past Three People
Branch names are a user interface for your team's work. The conventions that survive growth, the ones that collapse, and why boring always wins.