工具可能是最大的问题。所有（常见）开发工具都是围绕 1 project per repo 模型构建的。（Heroku，GitHub，CI，.）以及命令行工具。例如：GitHub当然“支持”monorepos，但你不能干净地“隔离”工作，这意味着其他项目的PR，issues，notofications，dependabot等，不断地泄漏到你的工作中。Git本身，再次：处理来自其他项目的“噪音”（分支、提交、钩子等）。CI：你如何装配它，使它只对“改变”的代码运行测试？
如果你只有12个团队，我根本不会担心效率。你可以用creating a monorepo测试它，看看它有多大和/或多慢。除非有一个项目每天都检查多GB的二进制文件，我敢打赌，你甚至不会注意到差异。
但是如果你问我，仅仅是一次性运行所有集成测试和在投入生产之前捕捉前端/后端损坏的好处就值得了。
†披露：我写了这个工具：）

一般来说，monorepos往往是一个坏主意。一些Git操作的执行与提交或其他对象的数量呈线性关系，这意味着将大量文件和大量提交放入一个存储库可能会导致您的存储库显着变慢。即使您现在没有遇到规模问题，将来也会遇到，在这一点上，将代码提取回多个存储库将变得更加困难。
有一些解决方案可以使monorepos的性能可以接受，例如Microsoft的VFS for Git。但是，最好不要首先使用它，因为它需要相当多的努力才能使事情正常工作。
您拥有的任何CI作业都将需要更长的时间来运行，因为它们需要更长的时间来克隆。您也可能会在每次任何项目更改时为整个monorepo而不是单个组件运行CI作业。
您还会发现，开发人员系统上的磁盘使用量可能会大大增加。原本只需要 checkout 几个仓库的开发人员现在需要更多的磁盘空间，这可能需要更大、更昂贵的机器或虚拟机。
最后，你的Git存储库会大得多。如果你在云上托管，这可能会给你带来问题。例如，Bitbucket将所有存储库限制在2 GB。如果存储库的大小开始给他们带来性能问题，其他提供商可能会要求你缩小存储库。即使你在本地托管，大型存储库也需要更多的时间来打包和重新打包，需要更多的CPU和内存来处理相同数量的用户。
您可以不使用monorepo，而是使用多个仓库的子模块，或者您可以简单地将当前版本的散列保存在仓库中的文件中，并让构建步骤检查它并在更改时构建它。这些解决方案适用于大型组织，它们可能也适用于您。