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

Question

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

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

根据这个： Visual Studio 建议 - 允许多个 Git 存储库同时处于活动状态，Visual Studio 似乎无法无缝支持许多 GIT 存储库。 （1995年请求）

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

顺便说一句（这不是主要问题 - 真正的问题在上一段中）：如果 Visual Studio 不允许同时激活多个 GIT 存储库，那么暂时坚持使用 TFS 不是更好对于公共库的任何开发？

Answer 1

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

• 单回购。 您的所有代码都位于一个存储库中，是否将它们拆分为单独的解决方案取决于您。 如果您的依赖项“可能可重用”，那么这是最简单的起点。 如果你真的开始重用你的组件，你总是可以将它们分解。
• 单独的存储库 + 包管理器（npm、Nuget） 。 将每个可重用项目放在单独的解决方案中，也可选择放在单独的存储库中。 让 CI 构建自动创建一个包并将其发布到 VSTS 包管理源。
• SubModules ：使用您的解决方案创建一个主存储库，为每个可重用组件创建一个单独的存储库，仅包含csproj和该组件的源代码。 Visual Studio 2017 对子模块提供基本支持。 但是如果有一个单独的 git 客户端（Tower、SourceTree）或者只是掌握了一些命令行，你就可以很好地完成这项工作。
• 子树：使用您的解决方案创建一个主存储库，为每个可重用组件创建一个单独的存储库，仅包含csproj和该组件的源。 Visual Studio 2017 目前不支持子树。 但是如果有一个单独的 git 客户端（Tower、SourceTree）或者只是掌握了一些命令行，你就可以很好地完成这项工作。
• Multi-repo ：为每个项目创建单独的存储库，并在其旁边放置一个解决方案。 单独管理每个子组件，没有子模块跟踪的概念。 Visual Studio 将在此设置中积极与您抗争，因为它一次仅支持一个主存储库

最终是你的选择。 每个解决方案都有自己的好处，并且有每个解决方案的例子。 Windows 源代码都存储在一个巨大的单一存储库中，所有可重用组件都存储在同一个存储库中。 在了解哪些文件和哪些版本可以一起工作以及哪些不能一起工作方面，它具有很大的优势。 但是存储库太大了，以至于 Microsoft 构建了 GVFS 以允许他们的开发人员在 300GB 的工作目录上工作。

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

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

Answer 2

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

有关更多信息，请参阅此博客： 在 Visual Studio 中使用 Git 提高生产力