每个项目使用 GIT 时的 Visual Studio 行为是什么？
What is the Visual Studio behavior when using GIT per project?
在阅读了关于将 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 是否会看到并管理每个 project/GIT 的更改，或者我是否必须在解决方案级别仅使用一个 GIT？
作为一个侧面（这不是主要问题 - 真正的问题在上一段）：如果 Visual Studio 不允许多个 GIT 存储库同时处于活动状态，对于任何使用公共库的开发，暂时坚持使用 TFS 不是更好吗？
这是一个有争议的话题。您有几个选择：
- Mono-repo。您的所有代码都位于一个存储库中，是否将它们拆分为单独的解决方案取决于您。如果您的依赖项“可能可重用”，那么这是最简单的起点。如果你真的开始重用你的组件，你总是可以分解它们。
- 独立存储库 + 包管理器（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），或者只是掌握了一些命令行，您就可以很好地完成这项工作。
- Multi-repo：为每个项目创建单独的存储库，并在其旁边放置一个解决方案。单独管理每个 sub-component 并且没有子模块跟踪的概念。 Visual Studio 将在此设置中积极与您对抗，因为它一次只支持一个主存储库
最后是你的选择。每个解决方案都有其自身的优势，并且每个解决方案都有示例。 Windows 源全部存储在一个巨大的 mono-repo 中，其所有可重用组件都在同一个存储库中。它在了解哪些文件和哪些版本可以一起工作以及哪些不能一起工作方面具有很大的优势。但是存储库太大，以至于微软构建了 GVFS 以允许他们的开发人员在 300GB 的工作目录上工作。
如果您的组件当前未 re-used 并且如果您的测试是集成测试而不是真正的单元测试，那么将它们加入同一个存储库是有意义的。
您可以随时决定在需要时修复此问题。您始终可以尝试将这些项目尽可能分开。 .NET 路线最合乎逻辑地会将您引向 Nuget...还因为它处理版本控制方面以及项目之间共享的便利性，而无需在各处构建源代码。
虽然过去对多回购解决方案的支持不多，但这种情况即将改变。在 Visual Studio 16.11 预览版 1 中，现在有一个功能更全面的 Git 客户端，检测到多个存储库，用户可以使用状态栏中的存储库选择器轻松地在它们之间切换。
有关详细信息，请参阅此博客：Enhanced Productivity with Git in Visual Studio
在阅读了关于将 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 是否会看到并管理每个 project/GIT 的更改，或者我是否必须在解决方案级别仅使用一个 GIT？
作为一个侧面（这不是主要问题 - 真正的问题在上一段）：如果 Visual Studio 不允许多个 GIT 存储库同时处于活动状态，对于任何使用公共库的开发，暂时坚持使用 TFS 不是更好吗？
这是一个有争议的话题。您有几个选择：
- Mono-repo。您的所有代码都位于一个存储库中，是否将它们拆分为单独的解决方案取决于您。如果您的依赖项“可能可重用”，那么这是最简单的起点。如果你真的开始重用你的组件，你总是可以分解它们。
- 独立存储库 + 包管理器（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），或者只是掌握了一些命令行，您就可以很好地完成这项工作。 - Multi-repo：为每个项目创建单独的存储库，并在其旁边放置一个解决方案。单独管理每个 sub-component 并且没有子模块跟踪的概念。 Visual Studio 将在此设置中积极与您对抗，因为它一次只支持一个主存储库
最后是你的选择。每个解决方案都有其自身的优势，并且每个解决方案都有示例。 Windows 源全部存储在一个巨大的 mono-repo 中，其所有可重用组件都在同一个存储库中。它在了解哪些文件和哪些版本可以一起工作以及哪些不能一起工作方面具有很大的优势。但是存储库太大，以至于微软构建了 GVFS 以允许他们的开发人员在 300GB 的工作目录上工作。
如果您的组件当前未 re-used 并且如果您的测试是集成测试而不是真正的单元测试，那么将它们加入同一个存储库是有意义的。
您可以随时决定在需要时修复此问题。您始终可以尝试将这些项目尽可能分开。 .NET 路线最合乎逻辑地会将您引向 Nuget...还因为它处理版本控制方面以及项目之间共享的便利性，而无需在各处构建源代码。
虽然过去对多回购解决方案的支持不多，但这种情况即将改变。在 Visual Studio 16.11 预览版 1 中，现在有一个功能更全面的 Git 客户端，检测到多个存储库，用户可以使用状态栏中的存储库选择器轻松地在它们之间切换。
有关详细信息，请参阅此博客：Enhanced Productivity with Git in Visual Studio