The merge queue
How many open PRs land without conflicts — file-overlap grouping and oldest-first ordering.
Run threads in parallel and you end up with something most teams never have to handle: many open pull requests, all ready at once. The merge queue is what keeps main releasable while they land.
Grouped by the files they touch
The queue doesn't treat open PRs as one long line. It groups them by the files each PR touches:
- PRs with no overlapping files are independent, so disjoint groups land in parallel.
- Within a group that shares files, the oldest merges first — the rest follow in order.
That ordering is the point. Two PRs that both edit the same module can't land simultaneously and discover the conflict halfway through; they queue behind each other, and each one merges against a main that already contains the one before it. Conflicts never surprise you mid-merge.
Working with auto-merge
The queue and auto-merge are made for each other. Arm auto-merge on a thread and its PR lands as its turn in the queue comes up and its checks are green. Leave it unarmed and the PR just waits for you — the queue never merges anything you haven't opted into.
Two halves of the same idea
Parallel work needs safety at both ends:
| Stage | What makes it safe |
|---|---|
| Working in parallel | Isolated sandboxes — one branch and one environment per thread, so agents can never step on each other |
| Landing in parallel | The merge queue — file-overlap grouping and oldest-first ordering, so branches can't step on each other either |
Isolation is what lets ten threads run at once. The merge queue is what lets ten branches land. Without it, parallelism would just move the pileup from your working tree to your PR list.
Before it reaches the queue
A PR enters the queue after Commit Thread opens it and its CI loop settles. If a thread has fallen behind while it waited, update from main brings it current in place — merge conflicts are flagged on the branch in the branch graph, so you see them before integrating rather than during.