原文链接：
Shopify 的 Merge Queue 实践很适合解释大团队为什么不能靠人工点 merge。
公开文章里，Shopify 提到他们在单体代码库上采用 trunk-based workflow，每天大量变更进入 master。随着团队规模上升，直接合并会带来软冲突、部署积压、事故期间继续合入等问题。
Shopify 总结过三条关键规则：
master 必须保持绿色master 不能离生产太远这三条非常适合普通团队借鉴。
主分支绿色，意味着开发者可以随时基于它工作。
主分支接近生产，意味着发布风险和回滚复杂度更低。
紧急修复足够快，意味着事故期间不会被长队列拖住。
单个 PR CI 通过，不代表多个 PR 连续合入后仍然通过。
Merge Queue 会把队列里的变更放到接近未来主分支的上下文中验证。
事故期间可以锁队列，阻止普通变更继续进入主分支，把通道留给紧急修复。
紧急绕过、队列失败、PR 被移出队列，都应该留下记录。
GitHub 原生 Merge Queue 已经提供通用能力，但 Shopify 的经验仍然有借鉴价值：
merge_group 或等价事件适合：
不适合：