Understanding the theory is necessary, but you also need to know how merge queues are implemented in the tools you'll actually use. The three most common implementations differ significantly in their defaults and capabilities.
GitHub Merge Queue (Native, 2023+)
GitHub's built-in merge queue is configured via branch protection rules. It supports both MERGE_COMMIT and SQUASH strategies, and uses optimistic merging by default.
Key configuration options in the branch protection rule:
- Merge method: Squash, Merge commit, or Rebase
- Build concurrency: How many speculative branches to run in parallel
- Minimum/maximum group size: For batching behavior
A GitHub Actions workflow must explicitly trigger on the merge_group event, alongside its usual push/pull_request triggers, for the merge queue to work at all. Without that trigger, GitHub's merge queue will not know which CI checks to wait for, and PRs will be merged without validation.
Mergify
Mergify is a third-party service (with a generous free tier) that adds a merge queue to any GitHub repository via a configuration file. It is more configurable than GitHub's native queue — its queue rules let you tune the speculative-execution depth, the batch size (how many PRs get grouped per CI run), and how long to wait before running a batch that hasn't filled up, alongside conditions like required approvals and passing checks before a PR is even added to the queue.
Bors-NG
Bors-NG is a self-hosted bot used by the Rust language project and other large open-source repositories. Developers interact with it via PR comments — approving a PR for merging, approving with elevated priority to jump the queue, cancelling a queued PR, or checking queue status, each via a distinct comment command.
Bors uses pure batching (no optimistic merging). It is battle-tested for repositories with slow CI and high contributor volume, but requires self-hosting and more operational overhead than GitHub's native queue or Mergify.