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

Question

在阅读了有关在 Visual Studio 解决方案中使用 GIT 的信息后，我了解到最好在每个项目中使用 GIT，至少对于代表(可重用)公共(public)库的项目来说是这样。如果您的解决方案包含许多特定于该解决方案的项目，则仅使用一个存储库是可以接受的。对于公共(public)库，对我来说，拥有一个存储库似乎是合乎逻辑的，以便能够从您检测到公共(public)库的位置修复公共(public)库中的错误，并且所有更改只有一份历史记录。

每个通用项目使用一个 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 不是更好目前是否有使用公共(public)库进行开发？

Answer 1

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

• 单一存储库。您的所有代码都位于一个存储库中，是否将它们拆分为单独的解决方案取决于您。如果您的依赖项“可能可重用”，那么这是最简单的起点。如果你真的开始重用你的组件，你总是可以将它们分解。
• 单独的存储库 + 包管理器(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 源代码全部存储在一个庞大的单一存储库中，其所有可重用组件都存储在同一个存储库中。它在了解哪些文件和版本可以一起工作以及哪些不能一起工作方面具有很大的优势。但存储库太大，以至于 Microsoft 构建了 GVFS，以便允许他们的开发人员在 300GB 的工作目录上工作。

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

您始终可以在需要时决定解决此问题。您始终可以尝试将这些项目尽可能分开。不过，从逻辑上讲，.NET 路线将引导您访问 Nuget...另外，因为它可以处理版本控制方面的问题，并且可以轻松地在项目之间共享，而无需在各处构建源代码。