即使在使用git时，我们通常认为我们应该按项目使用1个repo（大多数答案或建议都会告诉你这样做），也确实有将所有内容放在同一个仓库中的解决方案，这就是所谓的“monorepo”策略。
大的互联网公司都在做这件事（不仅仅是用git），比如谷歌，Facebook和微软（几乎）都在做这件事.所以你可以很容易地找到一些关于利弊的文档。
例如：https://github.com/babel/babel/blob/4c371132ae7321f6d08567eab54a59049e07f246/doc/design/monorepo.md
一旦你明白了版本控制工具的主要问题之一是性能（但git肯定可以支持5个开发团队），它更像是一个项目的感觉.
此外，如果你不满意，可以使用git命令分割仓库（保留历史记录），这比合并仓库要容易得多，所以这似乎是首先尝试的事情。
在我的团队中，我们越来越接近莫诺雷波。
我的5个开发团队维护一个由6个解决方案（又名部分）组成的中型应用程序。
如果这是一个应用程序，一个monorepo确实可能是一个很好的解决方案。
但是你必须解决的一个问题是，如果你在用nuget管理的解决方案之间存在依赖关系。
要么你删除nuget的使用，使用二进制依赖（没有签入它们！），所以你必须构建所有的依赖（但如果你想使用分支，这将是困难的）。
要么你接受提交2次来更新（就像你对多个git仓库所做的那样）。可以手动完成，也可以通过构建自动完成。
附言：git子模块很难，对于第一次使用git的用户来说不太好用......所以基于此的解决方案将是一个痛苦：-（
另一方面，一个Git仓库意味着对任何解决方案的更改都会导致TeamCity CI服务器上所有解决方案的全新完整重建。
不一定，您可以为每个解决方案生成不同的版本，并仅在其自己的解决方案文件夹中设置teamcity触发器。
PS 2：我做了一个更长的回答，预期;-）我希望它会有所帮助.

对于开源项目来说，如果你想让整个世界都能访问到你的数据库，那么你应该为每个项目都有一个存储库。许多开源项目的约定传统上都是为每个项目产生的包使用一个存储库，但随着围绕打包的既定约定和工具的改进，这种情况正在发生变化，以更好地支持多租户存储库。
对于内部工作来说，单个仓库（或者几个大仓库）是非常上级的，否则很难确保需要交互或共享资源的代码库之间的一致性。在真实的世界中，在许多仓库的每一种情况下，我都发现自己有额外的开销和同步问题，因为必须不必要地跨额外的仓库工作。
这里有一些警告。对于那些彼此无关的东西，它们可以很高兴地放在不同的仓库中。Git在mono-repos上也有一些缺陷。如果你把它和SVN比较，你会发现monorepo工作得很好（外部，不需要拉取整个repo，可以获得特定的文件夹等）。你可以绕过其中的一些，比如使用符号链接。

保持目前的方法，每个解决方案一个repo。如果需要，配置TeamCity仅基于某些repo的更改进行构建。我知道jenkins可以做到这一点。

我会将每个项目保存在自己的repo中，让构建服务器单独与它们交互。通过创建一个包含每个单独项目repo作为子模块的repo，您仍然可以简化开发人员的工作，并促进repo之间的更改协调。因此，开发人员可以查看大repo（通过子模块引用，它将获取项目仓库），构建服务器只是拉取项目仓库。

我知道这是一个老问题，但我只是想把Git OPS，基础设施作为代码的视角融入其中。
当你使用依赖于基于约定的命名和替换的高度参数化和模板化的IaC文件时，每个特性有一个Git仓库会更有意义。
在mono-repo中，您需要相当多的自定义IaC管道，这些管道可能不太标准化或可重用。