Table of contents
- What is a merge queue?
- GitHub merge queue
- GitLab merge train
- Graphite merge queue
- Feature comparison
- When to choose which
- Conclusion
What is a merge queue?
A merge queue is a system that lines up pull or merge requests and only merges them into the main branch after they pass CI checks combined with the latest base and preceding items. It ensures a consistently green main branch by preventing "merge skew" — when tests pass individually but fail in sequence due to rebases or conflicting changes.
Merge queues typically:
- Stack PRs in first-in-first-out order.
- Create temporary branches for grouped merges.
- Run CI on combined changes.
- Merge only passing sets.
- Drop failures and retry others.
You need one if:
- Your main branch frequently breaks.
- You have slow or expensive CI with high PR volume.
- You work in a trunk-based or multi-team setup.
- Manual rebasing or merge conflict handling becomes a bottleneck.
GitHub merge queue
How it works GitHub's merge queue is a native feature available through branch protection rules. When enabled, the "Merge" button becomes "Merge when ready." This triggers the creation of a temporary merge_group
branch containing the PR and any others in the queue. GitHub runs CI on this group before merging it sequentially to the base branch.
Pros
- Native to GitHub; no setup or extra tools required.
- Configurable merge methods, queue size, and CI concurrency.
- Prevents main from breaking by ensuring each PR is up to date with preceding changes.
- Integrated with GitHub permissions and visibility controls.
Cons
- Duplicates CI runs (on branch and on merge group), increasing CI cost.
- Limited visibility into failed merge group runs.
- Queue benefits are more noticeable at scale—small teams may see marginal gains.
Best for
- Teams fully using GitHub.
- High merge volume and long CI runs.
- Organizations that want native, enforced merge safety without extra tooling.
GitLab merge train
How it works GitLab's merge train feature merges requests in a queue-like structure. Each MR gets a temporary ref with the latest state of the branch and preceding MRs. Pipelines run in parallel on each cumulative state (e.g., base + MR1, base + MR1 + MR2), accelerating verification.
Pros
- Mature, built-in feature since GitLab 12.x.
- Supports parallel pipelines and semi-linear history.
- Transparent UI for managing train order and failures.
- Ideal for teams with long CI pipelines.
Cons
- Still duplicates CI for each merge state.
- Complex to understand and operate at first.
- Failing MRs can invalidate later ones, restarting their pipelines.
Best for
- GitLab users with high CI cost and long pipelines.
- Enterprises with strict merge quality needs.
- Teams that want a native and visible merge queue solution.
Graphite Merge Queue
How it works Graphite's merge queue is a GitHub-integrated, external system optimized for stacked pull requests and CI cost reduction. It rebases stacks onto the base branch and validates the group with CI, batching multiple PRs where possible.
Pros
- Stack-aware and optimized for stacked PR workflows.
- Reduces CI cost by batching multiple PRs into one pipeline.
- Supports fast-forward merges and parallel validation.
- Provides UI and CLI tooling for queue management.
Cons
- Requires installing the Graphite GitHub app.
- Cannot be used alongside GitHub's native merge queue.
- Learning curve for teams new to stacking or external tooling.
Best for
- Fast-moving teams using stacked PRs.
- Organizations with long CI runtimes.
- Teams looking to batch changes and save on CI cost.
Feature comparison
Feature | GitHub merge queue | GitLab merge train | Graphite Merge Queue |
---|---|---|---|
Native integration | ✅ | ✅ | ❌ |
FIFO + temp-branch CI | ✅ | ✅ | ✅ |
Parallel CI on queue | ✅ (configurable) | ✅ | ✅ |
Batching PRs | ❌ | ❌ | ✅ |
Stack-aware fast-forward | ❌ | ✅ (v16.5+) | ✅ |
CI cost efficiency | ❌ | ⚠️ | ✅ |
UI visibility/control | ⚠️ | ✅ | ✅ |
External tool required | ❌ | ❌ | ✅ |
Maturity level | New | Mature | Specialized |
When to choose which
- Choose GitHub merge queue if you're already on GitHub and want native protection for your main branch with minimal setup.
- Choose GitLab merge train if you're operating in GitLab and need a scalable, mature, parallel CI merge queue.
- Choose Graphite if your team uses stacked PRs, cares about CI speed and cost, and is open to adopting third-party tooling for a better developer experience.
Conclusion
Merge queues help teams ship safely and continuously by automating the hardest part of trunk-based development: merging at scale without breaking the main branch. Whether you go with GitHub's simplicity, GitLab's parallelism, or Graphite's performance-focused stack-aware model, introducing a merge queue is a strong step toward stability and velocity.