| English | 中文 |
Original links:
Shopify’s Merge Queue practice is highly suitable for explaining why large teams cannot rely on manual merge clicks.
In their public articles, Shopify mentions using a trunk-based workflow on a monolithic codebase, with massive amounts of changes entering master daily. As team size increases, direct merging leads to soft conflicts, deployment backlogs, and continued merges during incidents.
Shopify has summarized three key rules:
master must remain greenmaster cannot drift too far from productionThese three rules are highly adaptable for typical teams.
A green main branch means developers can base their work on it at any time.
A main branch close to production means lower release risks and lower rollback complexity.
Fast emergency fixes mean you won’t be delayed by a long queue during incidents.
A single PR passing CI does not guarantee that consecutive merges of multiple PRs will still pass.
Merge Queue places the changes in the queue into a context close to the future main branch for validation.
During incidents, the queue can be locked to prevent normal changes from continuing to enter the main branch, leaving the channel open for emergency fixes.
Emergency bypasses, queue failures, and PRs removed from the queue should all leave records.
GitHub native Merge Queue already provides generic capabilities, but Shopify’s experience still holds valuable lessons:
merge_group or equivalent eventsSuitable for:
Not suitable for: