Monorepo（单仓库）与Polyrepo（多仓库）的区别

软件开发团队和项目的扩展需要代码存储库结构。有两种最受欢迎的结构：Monorepo 和 Polyrepo，它们都是代码管理的模型，各有优缺点。将解释两者之间的区别以及优缺点，以帮助团队决定哪种更适合他们的工作流程。

什么是 Monorepo？

Monorepo 指的是将不同项目、包或服务的代码存储在一个存储库中。因此，所有可能创建的项目实际上都放置在一个存储库的统一结构中，但也可能包括服务、应用程序和其他库。

Google、Facebook 和 Uber 是使用 monorepo 的公司中的知名例子。例如，Google 有一个极其庞大的 monorepo，包含数十亿行代码，不同的团队可以在共享结构下高效地管理依赖关系并进行交互。

Monorepo 的关键特征

Monorepo 的关键特征

1. 单一存储库：所有项目和包都保存在一个存储库中。
2. 集中版本控制：所有代码库或绝大多数包都具有集中版本控制。
3. 通用工具和依赖项：开发工具、CI/CD 流程和依赖项对整个代码库是通用的。

什么是 Polyrepo？

Polyrepo 或多存储库是为每个项目或服务提供存储库的传统方法。这是大多数开源项目和小型公司组织代码的方法：每个存储库一个模块、微服务和项目。

微软和 GitHub 是其他公司和项目中的一些例子。这种设置在开源生态系统以及独立团队管理代码库的各个部分而无需与其他存储库持续集成的情况下非常有效。

Polyrepo 的关键特征

Polyrepo 的几个关键特征如下：

• 多个存储库：每个项目、服务或包都保存在其存储库中。
• 独立版本控制：每个存储库都有自己的版本控制。
• 专用工具和依赖项：所有开发工具、CI/CD 流程和依赖项对每个存储库都是独一无二的。

Monorepo 的优缺点

Monorepo 的几个优缺点如下：

优点

• 模块化开发：使用 monorepo，每个项目都有自己的存储库。这意味着团队可以独立工作，而不会影响其他项目。
• 访问控制：使用 Monorepo，团队可以管理自己的存储库，这使得根据需要设置特定权限变得容易。
• 精简的协作：将所有代码放在一个地方，可以促进跨团队协作。团队可以在其他团队的项目上工作，而无需特定的权限或存储库配置。
• 统一的 CI/CD 流水线：可以轻松地集中 CI/CD 流水线，从而减少了管理多个存储库上的 CI/CD 流程的开销。测试和部署整个代码库都在一个流水线配置中完成。
• 原子更改和重构：可以将影响多个项目的更改合并到单个提交中，这使得大型重构更加容易和安全。开发人员可以将他们的更新传播到所有项目。
• 版本控制简化：它们都使用整个代码库的一个版本，因此易于跟踪任何更改并同步更新依赖项。

缺点

• 存储库大小和性能问题：随着代码库的增长，存储库的大小（就 Git 操作而言）也会增加；大型 monorepo 会消耗大量计算能力，即使克隆一个大型 monorepo 也需要时间。
• 多个 CI/CD 管理的复杂性：虽然 monorepo 在某些方面简化了 CI/CD 流水线，但它们也使其复杂化。代码库某个部分中的更改可能会导致与给定更改无关的项目运行构建和测试，从而增加了 CI/CD 时间和资源利用率。
• 访问控制和权限：在 monorepo 中控制访问很困难，因为代码库的每个部分都有自己的要求，并且独立团队可能需要比在 monorepo 中更难强制执行的访问级别。
• 合并冲突和协作：使用上述任何策略，合并冲突都相当普遍，尤其是对于使用 monorepo 方法的大型团队。跨不同团队的审查也可能导致您的工作存储库中出现大量冲突和审查依赖项。
• 工具和基础设施开销：Monorepo 需要相当特定的工具和基础设施来运行。像 Bazel 和 Nx 这样的特殊工具专为管理与 monorepo 相关的复杂性而设计，但它们增加了额外的设置和维护成本。

Polyrepo 的优缺点

Polyrepo 的几个优缺点如下：

优点

• 模块化和独立开发：在 polyrepo 中，每个项目都有自己的存储库。因此，团队可以轻松地处理各种项目，开发人员不会影响与他们无关的项目。
• 它提供了更轻松的访问管理：Polyrepo 允许进行细粒度的访问控制，因为每个团队都对其存储库拥有完全控制权。因此，更容易根据每个团队的需求分配特定权限。
• 减少合并冲突：由于每个项目都有自己的存储库，因此合并冲突的数量仅限于特定项目。团队遇到跨代码库多个部分冲突的可能性较小。
• 带有独立版本控制的可扩展性：每个存储库都可以遵循自己的版本控制和发布周期。团队可以独立选择依赖项和升级包，而不会影响其他项目。

缺点

• 增加了依赖关系管理的复杂性：在 polyrepo 设置中，存储库之间的依赖关系管理具有挑战性。共享库或依赖项通常需要在每个存储库中手动更新，这会导致版本不匹配和有时会出现兼容性问题。
• 重复和不一致的标准：在没有集中工具的情况下，在维护一系列多个存储库的同时，保持团队编码标准、测试和质量应用的一致性变得相当难以管理。每个存储库可能都遵循应用于这些存储库的不同工具，从而增加了不一致性。
• 在 polyrepo 结构下操作以及团队在独立存储库中工作时存在挑战。

在开发人员一方为每个存储库设置权限，管理开销会增加。

跟踪和重构多个存储库中的代码

在跨多个存储库进行重构时会遇到困难。特别是，如果是 polyrepo，更改会影响一个以上的项目，这可能需要不同的拉取请求。这再次增加了代码不匹配的风险。

设置多个 CI/CD 基础设施

每个存储库都需要自己的 CI/CD 流水线，这会导致配置和资源利用率重复。团队将面临重复的设置和维护工作。

Monorepo 与 Polyrepo：选择哪一个？

monorepo 和 polyrepo 之间的选择将取决于组织的规模、项目的性质以及团队的偏好。

Monorepo 的用途

• 高度相互依赖的项目：在这些项目中，依赖关系更紧密耦合，而 monorepo 使依赖关系管理更简单并能实现更快的重构。
• 共享代码库，高协作：当两个团队紧密协作并共享相同的编码环境时，共享代码库有助于更轻松的协作。
• 集中式工具和自动化。偏好集中式 CI/CD、测试和代码质量，那么 monorepo 就有标准化的自动化。

与服务相互依赖的大型科技公司合作会更好。此外，目标一致、希望项目一致的团队，或者能够真正支持 monorepo 基础设施的团队。

Polyrepo 的用途

1. 独立团队和项目：如果项目不重叠并独立工作，polyrepos 可以为团队提供独立和灵活工作的空间。
2. 当不同的项目需要不同的访问级别时，polyrepos 可以非常轻松地满足所有这些需求。
3. 模块化和解耦的服务：Polyrepo 使得能够为微服务架构独立部署或扩展服务，而服务之间的依赖性最小。
4. 理想用于：开源项目、初创公司或拥有不依赖于共享代码库的独立产品线的公司。

示例和用例

1. Google Monorepo：Google 的 monorepo 使从事搜索、Android 和云服务的团队能够轻松共享依赖项。同时更改核心库会自动使 monorepo 中的所有服务受益。
2. Microsoft Polyrepo：微软在其存储库中对 VSCode 和 TypeScript 等开源项目采用了 polyrepo 方法。它支持独立发布和由独立团队维护，从而支持开源贡献。
3. Facebook 的混合方法：Facebook 的方法是混合的：他们对内部项目使用 monorepo，但对 React 和 Jest 等开源贡献使用 polyrepos。

结论

总之，monorepo 和 polyrepo 之间的争论没有简单的答案。两者都有各自的优点和缺点，但最终的决定通常取决于组织的具体需求。拥有紧密集成的服务和集中式资源的公司的 monorepo 可能受益匪浅。更侧重于独立、模块化开发或可能从 polyrepo 设置中受益更多的开源贡献的公司。

本质上，必须权衡项目依赖性、团队协作和基础设施能力等因素。