“不是火箭科学”——Bors 和谷歌的 TAP 如何启发了现代合并队列
原文英文，约3000词，阅读约需11分钟。
📝
内容提要
本文讨论了解决合并冲突的问题，介绍了早期的解决方案和现有的一些解决方案，如自动队列和批处理。大型科技公司和平台如谷歌、GitLab和GitHub也在努力提供类似的工具。
🔎
延伸解读
合并偏差：持续集成的隐藏成本
文章指出，即使每个PR都通过CI，合并偏差仍会导致主干破坏。当PR基于旧提交测试，而合并时主干已前进，语义冲突可能使测试失败。这种冲突的成本不是影响终端用户，而是拖累团队工程生产力。随着PR合并速率增加，冲突概率呈指数上升，每日可能造成数小时的主干中断。
从Bors到Google TAP：吞吐量的进化
Bors通过自动队列确保零偏差，但顺序执行CI导致吞吐量低下，例如40个PR/天、CI 15分钟时，一天只能合并32个。Google的TAP系统采用批处理和并行化，将未验证提交分批测试，失败时自动回滚和二分定位。这种设计在保证最终正确性的同时，支持每秒一次提交的高速度。
现代合并队列的普及与选择
GitHub和GitLab已推出原生合并队列功能，借鉴了Bors和Google的经验。这些工具支持并行CI和批处理，但配置和适用性因团队规模而异。文章认为，合并队列应成为标准解决方案，小公司也将逐渐采用。选择时需权衡吞吐量、延迟和正确性，避免简单队列成为新的瓶颈。
❓
Q&A
合并冲突的主要原因是什么？
合并偏差是导致合并冲突的主要原因，尤其在高耦合的代码库中。
Bors 是什么，它如何解决合并冲突？
Bors 是一种开源解决方案，通过自动排队来避免合并偏差，确保每个变更在合并前通过测试。
谷歌是如何处理合并队列的？
谷歌通过批处理和并行化来提高合并速度，使用双指针系统来管理代码库的合并。
合并冲突对团队生产力的影响是什么？
合并冲突会导致主干代码破坏，影响团队的工程生产力，造成工程师在不稳定的基础上工作。
如何解决合并偏差问题？
最简单的方法是强制要求状态检查通过，但在大规模团队中可能会变得繁琐，自动化队列是更好的解决方案。
GitHub 和 GitLab 如何应对合并冲突？
GitHub 和 GitLab 正在开发自己的合并队列功能，以应对高速度的开发需求。
🏷️
