2. V2EX
  3. Facebook 和 Google 的开发团队在想什么

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

383394544 2026-07-09 00:51 1

今天在微信某公众号看到一则文章，标题大约是"互联网巨头正在拋弃 Git"，点进去一看原来是点名了 M 和 G 两"巨头" ── 他们把所有项目放同个 repo 里（"monorepo"），结果现在 Git 不够用，于是他们转向别的版本管理框架。


该文指出了 monorepo 的几个"好处"，还痛斥 Linus 不为 M 和 G 的需求考虑。我看完觉得：难道拆分 repo 这个全世界 90% 以上的 git 用户都在用的 best practice 有问题吗？难道不是这两家前巨头在逆水行舟？

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

    而且我们每天合入的 PR 数量大概在 20 个左右，都是使用小 pr 快速提交快速合并，然后每天统一 rollout 两次，所有的服务都会被重新编译更新，这也是用大仓库比较方便的地方，盯着一个仓库的 CI ，CD 就可以了。
  • jianglai 07-09 03:53
    2楼
    我在 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 。
  • AmericanExpress 07-09 07:56
    3楼
    Monorepo 跟产品好坏有什么关系
  • PixelCode 07-09 09:31
    4楼
    monorepo 还是挺香的。真的是风水轮流转，刚开始 mono ，后来又拆，现在又回到 mono ，AI 时代 mono 更香
  • nc 07-09 17:13
    5楼
    Google 新产品差大概率是因为团队在用 Gemini 写代码，但内部框架 AI 训练资料不足，写出的代码质量就不高，比如 Gemini Web 版 UI 一堆 BUG 。
* 帖子来源V2EX
附近帖子
返回
飞读
随机推荐