Table of contents
- Understanding merge queues
- Why wait times vary (and why you should care)
- How Graphite cuts waiting times—and your CI bill
- Real gains in developer velocity
- So how long will your PR take?
- Getting started
- Final thoughts
Understanding merge queues
Imagine your team is racing toward a release. Everyone is pushing code, CI takes minutes, and before you know it, "main" is broken again because someone merged mid‑pipeline. Enter the merge queue: a traffic controller that ensures your trunk moves forward smoothly.
Instead of each dev merging directly, PRs are held in a queue. Once a PR passes initial CI, it's slotted in. The system then re‑validates it on top of the latest main and any PRs earlier in the queue. Only when it all checks out does it merge. This eliminates the chaos of "mid‑CI" commits landing and breaking main—a reliable bulwark for busy repos.
Why wait times vary (and why you should care)
When you ask "how long will it take?" here's what's really happening:
- Your PR waits in line—queue position × CI duration.
- If CI takes ~10 minutes, and you're third in line, you're looking at ~30 + next‑in‑line re‑validation.
- Retry loops due to flaky tests, or timeout bungles, can dramatically extend that time.
Worse yet: unoptimized queues run serial CI on each PR. Stacking PRs adds overhead—queues get slow fast if left unchecked.
How Graphite cuts waiting times—and your CI bill
Graphite's merge queue is a reliable option thanks to its "stack‑aware" architecture:
- Parallel CI inside a PR stack: if your feature spans PRs 1→2→3, CI runs concurrently across them, then merges as a fast‑forward if all clear.
- Parallel CI across stacks: multiple stacks or single PRs are processed in tandem—customers have seen ~1.5× faster merges (p75 down ~26%).
- Batching: combines CI for groups of stacks, reducing redundant work. Fallback on smart "bisecting" keeps things precise.
In plain English: Graphite runs fewer CI jobs, smarter and in parallel. Fewer redundant builds, faster merges, and less waiting in line.
Real gains in developer velocity
Before Graphite's stack‑aware queue, a 10‑minute build could balloon to 45‑plus minutes in a large batch—timeouts and test retries stacked painfully. Their rewrite introduced dynamic timeouts tied to stack size (and test flakiness), dramatically shrinking wait times and reducing constant CI reruns.
Let's break it down:
| Scenario | Traditional merge queue | Graphite stack-aware |
|---|---|---|
| CI per PR (10 min) | Serial: total = queue × 10 min | Parallel: total ≈ max(CI of any stack) + merge |
| Batch of 4 PRs | ~40 min before merge | ~10–15 min + fast‑forward |
| CI costs | High (4 CI runs × queue length) | Lower—shared tests, re-use across PRs |
So how long will your PR take?
It depends on:
- queue length.
- CI runtime and reliability.
- batching + parallelism.
For many teams:
- Traditional queues: position × CI time—so 5th in 10‑min CI queue = ~50 min wait.
- With Graphite opt‑ins: that might drop to ~10–20 minutes, thanks to parallel validation and fast‑forward merges.
And since Graphite runs smarter batches, you often hit your merge even faster.
Getting started
If you're on GitHub, Graphite integrates via the Graphite app or label system:
- Install Graphite on your repo
- Configure merge queue + optimizations (fast‑forward, batching, parallel CI)
- Optionally label "hot‑fix" PRs to jump queues
- Add PRs to queue via GitHub UI
- Monitor queues and ETAs from Graphite's dashboard
Final thoughts
Merge queues are the infrastructure that turns a messy "CI broken again" cycle into a smooth conveyor of safe, validated code. Out‑of‑the‑box queues help—but with serial CI, they still bog you down.
Graphite enhances that:
- stack‑aware CI, fast‑forward merges
- parallelism across stacks
- batching and dynamic timeouts
The result? Up to ~40–50% faster merges, reduced CI runs, happier developers, cleaner main. To learn more about the Graphite Merge Queue, check out our documentation.