C# 在每个项目中使用GIT时，VisualStudio的行为是什么？

在阅读了有关在VisualStudio解决方案中使用GIT的内容后，我了解到最好是在每个项目中使用GIT，至少对于表示（可重用）公共库的项目是这样。如果您有一个包含许多特定于该解决方案的项目的解决方案，那么只使用一个存储库是可以接受的。对于公共库，在我看来，为它设置一个存储库是合乎逻辑的，以便能够修复公共库中的bug，从中可以检测到它，并且所有更改只有一个历史记录

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

根据这一点，VisualStudio似乎无法无缝地支持许多GIT存储库。（1995年请求）

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

---

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

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

• 单一回购。您的所有代码都存在于一个存储库中，它们是否拆分为单独的解决方案取决于您。如果依赖项是“可能可重用的”，那么这是最简单的起点。如果你真的开始重用你的组件，你总是可以把它们拆开
• 独立存储库+包管理器（npm、Nuget）。将每个可重用项目放在单独的解决方案中，可以选择放在单独的存储库中。让CI生成自动创建包并将其发布到VSTS包管理源
• 子模块：使用您的解决方案创建一个主存储库，为每个可重用组件创建一个单独的存储库，仅使用

  csproj

  和该组件的源。Visual Studio 2017对子模块提供了基本支持。但是，如果有一个单独的git客户端（Tower、SourceTree），或者仅仅掌握一些命令行，就可以很好地完成这项工作
• 子树：使用您的解决方案创建一个主存储库，为每个可重用组件创建一个单独的存储库，只使用

  csproj

  和该组件的源。但是，如果有一个单独的git客户端（Tower、SourceTree），或者仅仅掌握一些命令行，就可以很好地完成这项工作
• 多重回购：为每个项目创建单独的存储库，并在其旁边放置一个解决方案。单独管理每个子组件，没有子模块跟踪的概念。VisualStudio将在此设置中积极地与您对抗，因为它一次只支持一个主存储库

最后，这是你的选择。每种解决方案都有其自身的优点，并且都有各自的例子。Windows源代码都存储在一个庞大的mono repo中，其所有可重用组件都存储在同一个存储库中。它在了解哪些文件、哪些版本可以协同工作，哪些版本不能协同工作方面有很大的优势。但是这个存储库太大了，微软为了让他们的开发人员能够在一个300GB的工作目录上工作而构建了GVFS

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

---

当需要时，您可以随时决定修复此问题。您可以始终尝试将这些项目尽可能分开。NET路径将最符合逻辑地引导您访问Nuget。。。另外，因为它可以处理版本控制方面以及项目之间的共享，而无需到处构建源代码。

虽然过去没有对多回购解决方案的强大支持，但这一点即将改变。在VisualStudio16.11预览版1中，现在有一个功能更加全面的Git客户端，可以检测到多个存储库，用户可以使用状态栏中的存储库选择器轻松地在它们之间切换

---

有关更多信息，请参阅本博客：

坚持使用TFS比使用GIT更好吗？您是否运行了许多TFS实例？确实应该用于这种类型的开发。取决于您正在使用的GIT扩展在UI中的支持程度。据我所知，我不确定GitLab。@P.Brian.Mackey，TFS是服务器基础（全局）。这意味着您可以对任何项目使用一个实例。每个项目只有一个历史记录。在VS中允许多个回购支持，我建议投票。@RonBeyer，我真的不是GIT专家。我认为使用子模块是一种可行的方法。这样做可以很好地与Visual Studio配合使用—一个解决方案和几个项目—特定于解决方案和公共LIB）？？？子模块GIT回购是否链接到父级？用户语音与我所指的链接相同！谢谢你的信息！！！