我想作为PM知道将多个回购合并为一个单回购所带来的潜在风险？
我曾尝试向首席工程师询问可能出什么问题，但他们非常愿意使用单独的存储库为12个团队完成此过渡，他们告诉我没有风险。
不适用
为回答这个问题，我希望我们能接受或减轻一系列合理的风险：
示例：
风险1：我们需要恢复到旧的回购协议，但不能，因为现在旧的回购协议已经落后了。
风险2：单个存储库的大小需要花费更长的时间才能下载，并且所有内容都需要克隆，而不是单个部分。
我知道以上内容是垃圾，为什么我要提建议...
谢谢
答案 0 :(得分：0)
通常，monorepos往往不是一个好主意。一些Git操作对提交或其他对象的数量线性执行，这意味着将大量文件和大量提交放入一个存储库可能会导致存储库的速度显着降低。即使您现在没有遇到规模问题，也可以在将来使用，到那时，将代码提取回多个存储库将变得更加困难。
有些解决方法可能会导致monorepos令人满意地执行，例如Microsoft的Vit for Git。但是，最好不要首先使用它，因为要使一切正常工作需要付出很多努力。
您拥有的所有CI作业都将需要更长的时间来运行，因为克隆它们将花费更长的时间。每当发生任何项目更改时，您也可能会为整个monorepo而不是单个组件运行CI作业。
您还将发现在开发人员系统上最终会占用更多磁盘。现在，可能只需要签出几个存储库的开发人员就需要更多的磁盘空间，这可能需要更大，更昂贵的计算机或VM。
最后，您的Git存储库将更大。如果您托管在云上，那可能会给您带来问题。例如，Bitbucket将所有存储库限制为2 GB。其他提供商可能会要求您缩小存储库，如果规模开始对他们造成性能问题。即使在本地托管，大型存储库也需要花费更多时间来打包和重新打包，这需要更多的CPU和内存来处理相同数量的用户。
您可以使用子模块用于多个存储库，而不必使用monorepo，或者可以简单地将当前版本的哈希保留在存储库中的文件中，并进行构建步骤将其检出并进行更改（如果已更改）。这些解决方案适用于大型组织，并且可能也适用于您。