传统n层设计中，具有多个项目的Git仓库最佳实践

Question

我正在从集中式的SCM系统转换到Git。好吧，我承认它是Visual SourceSafe。所以除了要克服Git命令和工作流程的学习曲线外，我目前面临的最大问题是如何在单个或某种多个存储库方面将我们当前的存储库迁移到Git。

我已经看到了各种方式提出这个问题，但通常只是基本的......“我有一些应用程序想共享一些较低级别的库”，而标准答案总是“使用单独的存储库”和/或“使用Git子模块”，没有解释在何时/为什么应该使用此模式（它克服了什么，它消除了什么？）。根据我目前有限的Git知识和阅读，似乎子模块可能会遇到自己的困难，尤其是对于新手来说。

然而，我尚未看到有人公然问，“当您拥有传统的n层开发（UI、业务、数据，然后是共享工具）每个层都是自己的项目时，应该使用一个还是多个存储库？”这对我来说并不清楚，因为几乎总是，当添加新的“功能”时，代码更改会影响每个层。

为了使项目/组件更易于管理，我们在“框架”中复制了这些层。就此讨论的目的而言，让我们称这些项目/层的集合为“Tahiti”，它代表了整个“产品”。

我们设置中的最后一层是添加客户端网站/项目，这些网站/项目会自定义/扩展Tahiti。在文件夹结构中表示这个可能看起来最好：

/Clients
  /Client1
  /Client2

/UI Layer
  /CoreWebsite (views/models/etc)
  /WebsiteHelper (contains 'web' helpers appropriate for any website)
  /Tahiti.WebsiteHelpers (contains 'web' helpers only appropriate for Tahiti sites)

/BusinessLayer (logic projects for different 'frameworks')
  /Framework1.Business
  /Framework2.Business

/DataLayer
  /Framework1.Data
  /Framework2.Data

/Core (projects that are shared tools useable by any project/layer)
  /SharedLib1
  /SharedLib2

在介绍了我们如何通过多个项目扩展传统的n层设计后，我想听听您在类似情况下做出的决策的经验（即使只是简单的UI、业务和数据分离也可以），以及由于您的决策而更容易/更困难的情况。我的初步理解是，子模块可能会有点烦人？比受益更大的烦恼？

我的第一反应是为Tahiti（除了“客户端项目”之外的所有项目）建立一个仓库，然后为每个客户端建立一个仓库。我猜整个Tahiti源码不到10k个文件。以下是我的理由（欢迎评论）：

- 在Git中，您似乎希望跟踪“功能”的历史记录，而不是单个“项目/文件”，即使我们对项目进行了分离，一个“功能”始终涵盖多个项目。 - 在核心站点编码的“功能”几乎总是最小影响核心网站和所有“框架”项目（即CoreWebsite、Framework1.Business、Framework1.Data）。 - 一个功能可以轻松地跨越多个框架（我会说我们实现的功能中有10%会跨越框架 - CoreWebsite、Framework1.Business、Framework1.Data、Framework2.Business、Framework2.Data）。 - 类似地，一个功能可能需要更改一个或多个SharedLib项目和/或“UI网站助手”项目。 - 对客户定制代码的更改几乎总是仅在其存储库中本地进行，不需要跟踪其他组件的更改以查看“整个功能更改集”。 - 鉴于一个功能跨越多个项目来查看整个范围，如果每个项目都是它自己的存储库，那么似乎很难尝试分析跨存储库的所有代码更改？

提前感谢。

- Terry

---

我们遇到了完全相同的问题，正在考虑使用 git subtree 来处理这些依赖项。 - Sardathrion - against SE abuse

Answer 1

大多数人建议使用单独的存储库，原因是它可以分离更改和变更集。如果某人对客户端项目进行更改（你说这并不会影响其他人），则没有理由让其他人更新整个代码库。他们只需获取所关心的项目中的更改即可。

Git子模块类似于Subversion中的Externals。您可以设置git存储库，使每个存储库成为单独的层次结构，并使用子模块将需要的项目包含在各种层次结构中。

例如：

/Core -- It's own git repository that contains it's base files (as you had outlined)
  /SharedLib1
  /SharedLib2

/UI Layer -- Own git repository 
  /CoreWebsite
  /WebsiteHelper
  /Tahiti.WebsiteHelpers
  /Core -- Git Submodule to the /Core repository
    /SharedLib1
    /SharedLib2

这确保了对/Core存储库的任何更新都会被带入UI Layer存储库。这也意味着，如果您必须更新共享库，您不必在5-6个项目中进行更新。

- Koby

---

这也意味着，如果您必须更新共享库，则无需在5-6个项目中进行更新...您的意思是我只需拉取Core而不是所有项目吗？在您的示例中，/Core物理文件夹是否真的位于硬盘上的/UI层下（除了位于/Core根目录下）？如果是（并且是子模块），它是否有自己的.git文件夹？ - Terry

是的，/Core会位于/"UI层"下，并拥有它自己的.git文件夹。如果您需要更改Core，您可以在/UI_Layer/Core文件夹中进行更改，提交并从那里推送到/Core repo，而无需将/Core放在自己的文件夹中。 - Koby

但是，当您的系统中有另一个文件夹中的/Core，例如因为它被/UI Layer 2使用，您必须拉取那个文件夹才能看到更改... @Koby，也许在您的答案中包含一些提示 ;) - Kjellski

Answer 2

VS 2022支持多仓库。

启用多仓库支持的最简单方法是使用CTRL+Q，键入“preview”并打开预览功能窗格。滚动到“启用多仓库支持”并切换复选框。此功能仍然是预览版功能，这意味着我们正在努力在即将发布的版本中添加更多支持。与此同时，我们依赖您的反馈和社区来构建您需要的功能。

请参见屏幕截图：

https://devblogs.microsoft.com/visualstudio/multi-repo-support-in-visual-studio/

- Visual Studio