Mono-repo和Multi-repo

什么是 Mono-repo?

在 mono-repo 方法中，你可以将所有服务保存在单一(mono)存储库中。你仍然可以独立地部署和管理每个服务。这些服务可以共享公共库和代码。
像 Facebook、 Google 和 Dropbox 这样的公司都使用 Mono-repo。
如果你把一个代码打包成公共的代码供大家go get
那么你会面临一个问题：
版本维护
假设A项目用了你的1.x 版本
B项目用了你的2.x的版本
c项目用了你的3.x的版本
所以随着项目的反正，你这个库会越来越大，越来越多的无用代码
最好的基本办法是什么：强制升级，有个问题 你很难知道谁用了你的代码， 别人不愿意升级
Mono-repo 的优势
Mon-repo 方式有许多优点

• 存储所有项目代码的单独位置，团队中的每个人都可以访问。
• 易于重用和共享代码，与团队合作。
• 就意味着基本上没有版本管理，只有最新版，我升级了版本，引用的地方就会报错
• 很容易理解你的变更对整个项目的影响。
• 代码重构和代码大变更的最佳选择。
• 团队成员可以获得整个项目的总体视图。
• 易于管理依赖关系。

Mono-repo 的劣势

当然，Mono-repo 也有一些缺点，主要表现在性能上。如果你的项目增长，每隔一天都会添加更多的文件，那么 git checkout、pull 和其他操作可能变得缓慢，以及文件搜索可能需要更长的时间。此外，如果你为你的项目雇佣了许多独立的承包商，那么让他们访问整个代码库可能不那么安全。此外，实现持续部署(Continuous deployation，CD)也很困难，因为许多人可以合入他们的更改，而持续集成(Continuous Integration，CI)系统可能需要进行多次重构。使用 Mono-repo 的大公司都有自定义工具来处理扩展问题。例如，Facebook 使用自定义文件系统和源代码控制。

什么是 Multi-repo?

在 Multi-repo 方法中，存在多个存储库，它们承载一个项目的多个库和服务。如果服务发生更改，开发人员只需重新构建该服务，而不需要构建整个项目。个人和团队可以从事他们特定的服务，他们只能访问他们有权限的服务。
像 Netflix 和 Amazon 这样的公司使用 Multi-repo。
Multi-repo 的优势?
采用 Multi-repo 的公司数量远远多于采用 Mono-repo 的公司，原因如下:

1. 每个服务和库都有自己的版本控制。
2. 代码 checkout 和 pull 是小型且独立的，因此即使项目规模增大，也不存在性能问题。
3. 团队可以独立工作，不需要访问整个代码库。
4. 更快的开发和灵活性。
5. 每个服务都可以单独发版，并有自己的部署周期，从而使 CI 和 CD 更易于实现。
6. 更好的权限访问控制——所有的团队不需要完全访问所有的库——需要的时候，再获得读访问权限。
   Multi-repo 的劣势

• 跨服务和项目使用的公共依赖和库必须定期同步以获得最新版本。
• 某种程度上鼓励孤立文化，导致重复代码和各个团队试图解决相同问题。
• 每个团队可能遵循不同的一组最佳实践来编写代码，从而导致难以遵循通用的最佳实践。