我的5个开发团队维护一个中等规模的应用程序，由6个解决方案组成（又名部分）。目前，我们使用TFS进行源代码管理。每个解决方案都位于其主分支中。一个大的Git回购或多个小的回购
我想迁移到Git。我的问题是是否对所有6种解决方案都有1个Git回购，或者对每种解决方案使用单独的Git回购。
吸引我有一个单一的Git回购，这是因为：
另一方面，一个单一的Git仓库就意味着对任何解决方案的更改都会导致我们的TeamCity CI服务器上的所有解决方案全面重新生成。
寻找来自其他团队负责人在这个问题上的一些见解。
即使在使用git时，它目前承认按项目使用1个回购（并且大部分答案或建议都会告诉你这样做），但它们确实是将所有内容放入同一个存储库的解决方案，称为'monorepo'战略。 （谷歌，Facebook和微软）正在（几乎）走向它......所以你可以很容易找到一些关于正反两面的文档。
例：https://github.com/babel/babel/blob/4c371132ae7321f6d08567eab54a59049e07f246/doc/design/monorepo.md
一旦你了解的主要问题之一是版本控制工具的性能（但混帐肯定可以支持5开发团队），它更像是一个项目的感觉......因为它似乎你似乎已经看到了一些优势，我强烈建议你测试它！
此外，如果您不满意，则用于拆分存储库（保留历史记录）的git命令比合并存储库容易得多，因此似乎首先尝试。
在我的团队中，我们越来越趋向monorepo。
我的5个开发团队维护一个由6个解决方案（又名部分）组成的中型应用程序。
如果这是一个应用程序，monorepo确实可能是最好的解决方案。
但是，如果您在使用nuget管理的解决方案之间存在依赖关系，则必须解决该问题。
要么你删除的NuGet使用，并且使用二进制依赖（没有办理入住手续的他们！），所以你必须建立所有（但如果你想用树枝将是困难的）。
要么你接受，使2个提交做一个更新（如你有多个Git仓库做）。可以手动完成或通过构建自动完成。
PS：git的子模块是困难的，不是很劝了git的用户第一次......所以基于这样一个解决方案将是:-(
疼痛。另一方面，一个单一的Git回购意味着更改任何方案导致一个新的完整的重建我们的TeamCity CI服务器上的所有解决方案。
不一定，你可以做出不同的构建为每个解决方案，并设置每个TeamCity的触发仅在自己的解决方案文件夹。
Ps2：我做了一个更长的回答，期待;-)我希望这会有所帮助...
保持现有方法，每个解决方案只有一个回购。如果需要，可以将TeamCity配置为仅基于特定回购中的更改进行构建。我知道詹金斯可以做到这一点。
我会保持每个项目在自己的回购，并让建设服务器与他们分别进行交互。您仍然可以简化开发人员的工作，并通过创建一个包含每个项目回购作为子模块的单个回购协议来促进跨回购的变更协调。因此，开发人员检查大回购（通过子模块引用，将获得项目回购），而构建服务器只需要取回项目回购。
对于开放源代码，您想在其中公开VCS对整个世界的访问，那么您应该为每个项目存储一个存储库。
对于内部工作单个存储库（或几个大仓库）是远远优于。如果要确保需要交互或共享资源的代码库之间的一致性，那么很难做到。在现实世界中，在任何有许多存储库的情况下，我发现自己在额外开销和syncronisation问题上遇到问题，这些问题需要通过不必要的方式跨越其他存储库。
有警告。对于彼此无关的事情，他们可以愉快地在单独的存储库中。 Git在mono-repos中也存在一些缺陷。你会看到这个，如果你把它与SVN中的monorepo工作得很好（外部，不需要拉整个回购，可以得到一个特定的文件夹等）。你可以通过使用符号链接来解决其中的一些问题。
如果你的团队没有很多的经验与子模块，然后我会建议对这一做法。子模块在纸上很酷，但实际上它们确实会造成混乱。 – zypherman
“如果你没有经验与他们，不要获得与他们的经验”？如果你对他们有一个具体的问题，我会很有兴趣知道这件事，但是这听起来像是一种FUD的人，如果他们没有 - 也不想 - 学习如何正确使用一个功能。 –