今天在微信某公众号看到一则文章，标题大约是"互联网巨头正在拋弃 Git"，点进去一看原来是点名了 M 和 G 两"巨头" ── 他们把所有项目放同个 repo 里（"monorepo"），结果现在 Git 不够用，于是他们转向别的版本管理框架。 该文指出了 monorepo 的几个"好处"，还痛斥 Linus 不为 M 和 G 的需求考虑。我看完觉得：难道拆分 repo 这个全世界 90% 以上的 git 用户都在用的 best practice 有问题吗？难道不是这两家前巨头在逆水行舟？ monorepo, git, 版本管理
这个也算是个月经问题了。 我个人是喜欢 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 。
