主要观点：作为新兴开发者生产力团队的工程师，若组织决定走向单体仓库（monorepo），需了解前行之路。首先要明确为何要使用 monorepo，原因应是一致性、组织连贯性和共享工具努力，而非受大公司博客影响。

关键信息：

• 单体仓库相关工程工具的黄金法则是任何对仓库的操作需为 O(change)而非 O(repo)。
• 存储所有源代码在一个仓库会带来性能问题，如 git 在大型仓库中会变慢，可选择 fork git 或 Mercurial 等，也可自行编写源控制系统。
• 保持 monorepo 单语言可提高一致性，利用语言生态的构建系统，构建系统需具备高效构建目标和确定受更改影响目标的能力。
• 测试系统需更智能，自动重试失败测试，只运行必要测试，语言生态的默认测试系统可能需要扩展。
• CI 系统要根据更改范围生成构建工件和运行验证，多语言仓库中解决此问题有挑战，不同项目有不同做法，需在吞吐量、正确性和尾延迟间权衡。
• 单体仓库虽可实现原子提交，但从部署角度看并非如此，用户需理解部署系统与 monorepo 的异步性，CI 工作要验证服务合同。

重要细节：

• Google 用 Piper 作为内部 monorepo 的源控制系统，Meta 用 Sapling 且是 Mercurial 的修改版。
• 如 Rust 的 nextest、Java 的 JUnit 等语言生态的测试系统具备所需功能。
• 不同项目如 Rust 用 bors、Chromium 类似做法、Uber 利用构建图知识确定并发提交等。
• 单体仓库的最大谎言是可在整个代码库进行原子提交，但从部署角度看并非如此，会导致事故。

总结：monorepo 是强大工具，但实现高效需做很多工程工作，是持续过程，若愿意投入则值得。