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

Question

在阅读了有关将 GIT 与 Visual Studio 解决方案结合使用的信息后，我了解到最好在每个项目中使用 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 存储库，那么坚持使用 TFS 会更好目前是否有任何使用公共库的开发？

Answer 1

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

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

Answer 2

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

• 单一回购。您的所有代码都位于一个存储库中，是否将它们拆分为单独的解决方案取决于您。如果您的依赖项“可能可重用”，那么这是最简单的起点。如果您真的开始重用您的组件，您可以随时将它们拆分出来。
• 单独的存储库 + 包管理器（npm、Nuget）。将每个可重用项目放在单独的解决方案中，也可选择放在单独的存储库中。让 CI 构建自动创建一个包并将其发布到 VSTS 包管理源。
• SubModules：使用您的解决方案创建一个主存储库，为每个可重用组件创建一个单独的存储库，其中仅包含 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 源代码都存储在一个巨大的单一存储库中，其所有可重用组件都存储在同一个存储库中。它在了解哪些文件和哪些版本可以一起工作以及哪些不能一起工作方面具有很大的优势。但是存储库太大了，以至于微软构建了 GVFS 以允许他们的开发人员在 300GB 的工作目录上工作。

如果您的组件当前没有被重用，并且如果您的测试是更多的集成测试而不是真正的单元测试，那么将它们加入同一个存储库是有意义的。

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