每个项目使用GIT时Visual Studio的行为是什么？

Question

在阅读了有关在Visual Studio解决方案中使用GIT之后，我理解每个项目最好使用GIT，至少对于代表（可重用）公共库的项目。如果您的解决方案包含特定于该解决方案的许多项目，则只能使用一个存储库。对于公共库，我有逻辑地拥有一个存储库，以便能够修复公共库中的错误，从中检测到错误，并且只有一个历史记录可用于所有更改。

每个通用项目使用一个GIT意味着您可以为任何生成使用一个或多个公共库的可执行文件的解决方案拥有多个GIT存储库。

根据这个：Visual Studio suggestion - Allow multiple Git repositories to be active at once，Visual Studio似乎无法无缝地支持许多GIT存储库。 （1995年请求）

Visual Studio 2017是否实现了以前的建议并为每个解决方案管理了许多GIT存储库？ （例如：某些项目的每个项目一个，解决方案本身的解决方案和解决方案的所有其他特定项目）换句话说，Microsoft是否会查看和管理每个项目/ GIT的更改，或者我是否必须在解决方案级别只使用一个GIT？

就像一方（这不是主要问题 - 真正的问题在前一段）：如果Visual Studio不允许同时激活多个GIT repo，那么坚持使用TFS会更好对于使用通用库进行任何开发的那一刻？

Answer 1

虽然过去对多存储库解决方案没有很好的支持，但这种情况即将改变。在 Visual Studio 16.11 Preview 1 中，现在有一个功能更齐全的 Git 客户端，可以检测到多个存储库，用户可以使用状态栏中的存储库选择器轻松地在它们之间切换。

有关详细信息，请参阅此博客：Enhanced Productivity with Git in Visual Studio

Answer 2

这是一个有争议的话题。您有几个选择：

• 的单 - 回购即可。您的所有代码都存在于一个存储库中，无论它们是否分成单独的解决方案都取决于您。如果您的依赖项“可能可重用”，那么这是最简单的起点。如果您真的开始重用组件，可以随时将它们分解出来。
• 单独的存储库+包管理器（npm，Nuget）。将每个可重用项目放在单独的解决方案中，可选择在单独的存储库中。让CI构建自动创建包并将其发布到VSTS包管理订阅源。
• 子模块：使用您的解决方案创建主存储库，为每个可重用组件创建一个单独的存储库，其中只包含csproj和该组件的源。 Visual Studio 2017对子模块提供了基本的支持。但是如果有一个单独的git客户端（Tower，SourceTree）或只是一些命令行掌握，你可以使这项工作正常。
• 子树：使用您的解决方案创建一个主存储库，为每个可重用组件创建一个单独的存储库，只包含csproj和该组件的源。 Visual Studio 2017 has no support for subtrees at the moment。但是如果有一个单独的git客户端（Tower，SourceTree）或只是一些命令行掌握，你可以使这项工作正常。
• 多回购：为每个项目创建单独的存储库，并在其旁边提供解决方案。分别管理每个子组件，没有子模块跟踪的概念。 Visual Studio将在此设置中主动与您对抗，因为它一次只支持一个主存储库

最后，这是你的选择。每个解决方案都有其自身的优势，每个解决方案都有各自的例子。 Windows源代码都存储在一个monstrous mono-repo中，其所有可重用组件都在同一个存储库中。它在知道哪些文件和哪些版本一起工作以及哪些不兼容方面具有很大的优势。但是存储库是如此之大，以至于微软构建了GVFS以允许他们的开发人员在300GB的工作目录上工作。

如果您的组件当前没有被重复使用，并且您的测试是比实际单元测试更多的集成测试，那么将它们连接到同一个存储库是有意义的。

您可以随时决定在需要时解决此问题。您始终可以尝试将这些项目尽可能分开。 .NET路由在逻辑上会引导您进入Nuget ...同时因为它处理版本控制方面和项目之间的共享，而无需在任何地方构建源代码。