Facebook 和 Google 的开发团队在想什么

这个也算是个月经问题了。
我个人是喜欢 monorepo ，只是普通公司的基建难以支撑一个公司只用一个仓库而已。
我们现在的团队和之前鹅肠的团队，都是后端就一整个 repo ，虽然不算古典 monorepo ，但带来了极大的便利，尤其是现在对 AI 来说，分散到各处的 repo 不如合到一起。我现在就不得不把前端和 app 的 repo 下下来并告诉 claude 在哪里才能进行 e2e 分析，我觉得这比每个服务都被拆分到一个 repo 中要容易的多。而且对于 golang 来说，这意味着我们只需要管理一份根目录的 go.mod ，所有 share 的 pkg 只会有一个版本，要轻松很多。

而且我们每天合入的 PR 数量大概在 20 个左右，都是使用小 pr 快速提交快速合并，然后每天统一 rollout 两次，所有的服务都会被重新编译更新，这也是用大仓库比较方便的地方，盯着一个仓库的 CI ，CD 就可以了。

我在 G 和 F 都待过，monorepo 用 valina git 是不行的，G 原来有自己的 perforce fork ，现在用的 fig 是 hg 的 fork ，F 用的 sapling 也是 hg 的 fork 。

monorepo 的主要好处是 no versioning ，always living on master ，不需要考虑 version conflict 的问题。这对于 G 和 F 这样的大厂，是非常提高工作效率的，所有的 team 都只需要保持一个 branch 。同时这对 CI/CD 的要求就很高，需要保证每次 commit 都不会 break master 。

Monorepo 跟产品好坏有什么关系

monorepo 还是挺香的。真的是风水轮流转，刚开始 mono ，后来又拆，现在又回到 mono ，AI 时代 mono 更香

Google 新产品差大概率是因为团队在用 Gemini 写代码，但内部框架 AI 训练资料不足，写出的代码质量就不高，比如 Gemini Web 版 UI 一堆 BUG 。