How does GitHub's pull request merge queue work?

Merge queue (GitHub feature) solves a common problem: multiple approved PRs pile up, all passing CI, but each was tested against the main branch from before the others merged. If PR #1 and PR #2 both pass tests independently but conflict when both are merged, you discover the issue after merging. Merge queue addresses this by testing PRs in merge order before actually merging them. How it works: (1) PR is approved and added to the queue; (2) GitHub creates a temporary merge branch combining main + all queued PRs in order; (3) CI runs on this temporary branch; (4) If all checks pass, the actual merge happens; (5) If a PR's check fails, it's removed from the queue; subsequent PRs are retested without it. Benefits: guarantees the state of main after merge matches what was tested; eliminates "merge race conditions"; allows multiple PRs to progress simultaneously; especially valuable for high-throughput teams with many concurrent PRs. Configuration: in branch protection rules, enable "Require merge queue" and configure batch size and timeout. Alternative without merge queue: require PRs to be up to date with main before merging (manually rebase/merge main into PR) — works but creates bottleneck serializing all merges.