您是否相信 Google、Meta、Uber、Twitter 和 Airbnb 将几乎所有代码都放在一个存储库中？
这种做法称为 monorepo。
Monorepo 与 Microrepo。哪个是最好的？为什么不同的公司会选择不同的方案？
Monorepo 并不新鲜； Linux 和 Windows 都是使用 Monorepo 创建的。为了提高可扩展性和构建速度，Google 开发了内部专用工具链以更快地扩展它，并制定严格的编码质量标准以保持其一致性。
亚马逊和 Netflix 是微服务理念的主要大使。这种方法自然地将服务代码分离到单独的存储库中。它的扩展速度更快，但随后可能会导致治理痛点。
在 Monorepo 中，每个服务都是一个文件夹，每个文件夹都有一个 BUILD 配置和 OWNERS 权限控制。每个服务成员都对自己的文件夹负责。
另一方面，在 Microrepo 中，每个服务对其存储库负责，通常为整个存储库设置构建配置和权限。
在 Monorepo 中，无论您的业务如何，依赖项都会在整个代码库中共享，因此当版本升级时，每个代码库都会升级其版本。
在 Microrepo 中，依赖关系在每个存储库内进行控制。企业根据自己的时间表选择何时升级版本。
Monorepo 有一个签入标准。 Google 的代码审查流程以设定高标准而闻名，无论业务如何，都能确保 Monorepo 保持一致的质量标准。
Microrepo 可以设置自己的标准，也可以通过结合最佳实践来采用共享标准。它可以更快地扩展业务，但代码质量可能会有所不同。
Google 工程师构建了 Bazel，Meta 构建了 Buck。还有其他可用的开源工具，包括 Nix、Lerna 等。
多年来，Microrepo 拥有了更多支持的工具，包括用于 Java 的 Maven 和 Gradle、用于 NodeJS 的 NPM 以及用于 C/C++ 的 CMake 等。
没有在大型设置中使用过 monorepo，但我能想象到的只是一场噩梦
1.制定代码标准——格式化、代码质量评估。要么每次有新人加入时，您都必须采用最小公分母来避免此类对话，要么您花费无尽的时间争论和争论对客户来说不重要的事情
2. 依赖关系管理 - 团队不会花时间测试其依赖关系的升级，即使这对他们的“自己的服务”并不紧急/关键？
只是好奇，所以让我们说在谷歌，你在获取最新更改时是否提取整个源代码，或者有一些聪明的方法只部分检查相关的源文件？如果您的运营规模如此之大，那么拉动整个事情也是没有意义的，您将不得不在工具上投入大量资金来支持如此大规模的单一存储库
您只有通过界面直接在服务器上编辑或编码的文件的副本。所有建筑都在服务器上。由于事情很忙，它可能会有点慢，但它确实有效。在我看来，最大的痛苦是没有版本控制，所有文件都位于头部。处理版本化的外部库非常困难，因为如果升级库，您必须修复所有依赖项。如果没有这条规则，情况可能会更糟，但这是一个很大的摩擦。
我想尝试将几个大型代码库整合到一个单一存储库中，只是为了尝试一下，但这感觉就像是一场单程之旅。如果它不起作用，就没有办法退出，除非我弄错了