git - 在 Visual Studio 中使用 git 子模块的工作流程

Question

我有一些共享代码，我想在多个解决方案中共享。大多数示例使用命令行，但我想使用 Visual Studio 2013(和/或 TortoiseGit)来完成？

- SolutionShared
  - .git
  - Project1Shared
  - Project2Shared
- Solution1
  - .git
  - ProjectFoo
  - ProjectBar
  - [SolutionShared]
    - [Project1Shared]
    - [Project2Shared]
- Solution2
  - .git
  - ProjectBaz
  - ProjectQux
  - [SolutionShared]
    - [Project1Shared]
    - [Project2Shared]

我所做的是创建一个新的解决方案 SolutionShared，将我所有的共享代码添加到那里，并将其添加到它自己的 git 存储库中。然后我使用 TortoiseGit(因为我无法弄清楚如何在 Visual Studio 中执行此操作)将该共享存储库作为 git 子模块添加到 Solution1 和 Solution2。

<强>1。我在 Visual Studio 中做什么？
我的两个解决方案现在都有一个 SolutionShared 目录。我是否只需在 Visual Studio 中添加它的两个子项目(Project1Shared 和 Project2Shared)？

<强>2。如何从非共享项目中更改共享代码
如果我在其中一个非共享解决方案中并对子模块中的某些内容进行了更改，我该如何提交并将其推送回共享解决方案的存储库 (SolutionShared) 以便它可供使用所有引用它的解决方案？

Answer 1

我们发现最简单的方法是将我们的每个共享代码单元移动到它们自己的 Visual Studio 项目中，并将每个共享的 Visual Studio 项目放在它自己的存储库中。

然后，我们将这些项目中的每一个作为子模块添加到需要它们的任何解决方案中。这很有用，因为我们的许多项目的规模可能非常大，并且共享许多相同的代码块。为此，我们也广泛使用了 nuget 包，但通常取得了更好的成功，并且子模块的设计/调试体验也更好。

在过去几年中，Microsoft 在 Git 方面发生了很大变化。 Visual Studio Team Services (TFS Online) 和 On Prem-TFS(自 TFS2015 起)现在都对子模块的工作原理有了很好的理解，并且现在可以执行包含开箱即用的子模块的 CI 构建。

但是，对本地 TFS 2015 的支持可能有点问题。 TFS Build 对子模块的引用通常会损坏，导致构建在没有警告的情况下停止工作，直到有问题的子模块被完全删除并重新添加——这不是一个有趣的过程。出于这个原因(以及其他一些原因)，我们现在对所有内容都使用 VSTS(TFS Online)并且没有遇到任何相同类型的问题。我假设这也已在本地 TFS 2017 中修复。

如前所述，Visual Studio 本身(IDE)仍然很难理解子模块关系。它真的无法处理它们。我已经尝试了许多独立的 Git 工具来找到管理这样的环境的最简单方法。在推送、 pull 和 checkin 包含子模块的存储库时，Tortoise 似乎提供了最简单和最高效的体验。我通常使用命令来添加子模块，但我怀疑 Tortoise 的添加子模块功能也能正常工作。

当您使用 Tortoise 将代码提交到存储库时，它会注意到子模块何时变脏，并会提示您在检入父存储库之前先检入子模块。这是非常好的。不过， pull 或获取父存储库可能有点令人困惑。它实际上并没有从它的远程分支刷新子模块，它只是将它刷新到当前检查到主 repo 远程的任何级别，这并不总是最新的。实际上，这是期望的行为，如果您不期望它，它不会立即直观。