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

Best Practice for Git Repositories with multiple projects in traditional n-tier design

提问by Terry

I'm making the switch from a centralized SCM system to GIT. OK, I'll admit which one, it is Visual SourceSafe. So in addition to getting over the learning curve of Git commands and workflow, the biggest issue I'm currently facing is how to migrate our current repository over to Git in regards to single or some flavor of multiple repositories.

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

I've seen this question asked in a variety of ways, but normally just the basic..."I have applications that want to share some lower level libraries" and the canned response is always "use separate repositories" and/or "use Git submodules" without much explanation of when/why this pattern should be used (what does it overcome, what does it eliminate?) From my limited knowledge/reading on Git so far, it appears that submodules may have their own demons to battle, especially for someone new to Git.

我已经看到以各种方式提出这个问题，但通常只是基本的......“我有想要共享一些较低级别库的应用程序”，并且固定响应始终是“使用单独的存储库”和/或“使用Git submodules” 没有太多解释何时/为什么应该使用这种模式（它克服了什么，它消除了什么？）从我目前对 Git 的有限知识/阅读来看，似乎子模块可能有自己的恶魔要战斗，特别是对于 Git 新手。

However, what I've yet to see someone blatantly ask is, "When you have the traditional n-tier development (UI, Business, Data, and then Shared Tools) where each layer is its own project, should you use one or multiple repositories?" It is not clear to me because almost always, when a new 'feature' is added, code changes ripple through each layer.

然而，我还没有看到有人公然问的是，“当你有传统的 n 层开发（UI、业务、数据，然后是共享工具），其中每一层都是自己的项目时，你应该使用一个还是多个？存储库？” 我不清楚，因为几乎总是，当添加新的“功能”时，代码更改会在每一层中产生涟漪。

To complicate matters with respect to Git, we've duplicated these layers across 'frameworks' to make more manageable projects/components from a developer's perspective. For the purpose of this discussion, lets call these collection of projects/layers 'Tahiti', which represents an entire 'product'.

为了使与 Git 相关的问题复杂化，我们在“框架”中复制了这些层，以从开发人员的角度创建更易于管理的项目/组件。出于本次讨论的目的，我们将这些项目/层的集合称为“Tahiti”，代表整个“产品”。

The final 'layer' in our set up is the addition of client websites/projects which customize/expand upon Tahiti. Representing this in a folder structure might best look like:

我们设置中的最后一个“层”是添加自定义/扩展大溪地的客户网站/项目。在文件夹结构中表示它最好看起来像：

/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

After explaining how we've expanded on the traditional n-tier design with multiple projects, I'm looking for any experience on what decision you've made with a similar situation (even the simple UI, Business, Data separation was all that you used) and what was easier/harder because of your decision. Am I right in my preliminary reading on how submodules can be a bit of pain? More pain than is worth the benefit?

在解释了我们如何通过多个项目扩展传统的 n 层设计之后，我正在寻找关于您在类似情况下做出的决定的任何经验（即使是简单的 UI、业务、数据分离也是您的全部）使用）以及由于您的决定而更容易/更困难的事情。我对子模块如何可能有点痛苦的初步阅读正确吗？比获得的好处更多的痛苦？

My gut reaction is to one repository for Tahiti (all projects excluding the 'client projects'), then one repository for each client. The entire Tahiti source I'm guessing has to be <10k files. Here is my reasoning (and I welcome criticism)

我的直觉反应是为 Tahiti 建立一个存储库（所有项目，不包括“客户项目”），然后为每个客户建立一个存储库。我猜整个 Tahiti 源文件必须小于 10k 个文件。这是我的推理（我欢迎批评）

• It seems to me, that in Git you want to track history of 'features' vs individual 'projects/files', and even with our project separation, a 'feature' will always span multiple projects.
• A 'feature' coded in the core site will almost always minimally effect the core website and all projects for a 'framework' (i.e. CoreWebsite, Framework1.Business, Framework1.Data)
• A feature can easily span multiple frameworks (I'd say 10% of the features we implement would span frameworks - CoreWebsite, Framework1.Business, Framework1.Data, Framework2.Business, Framework2.Data)
• In a similar fashion, a feature could require changes to 1 or more SharedLib projects and/or the 'UI website helper' projects.
• Changes to client's custom code will almost always only be local to their repository and not require tracking changes to other components to see what the 'entire feature change set' was.
• Given that a feature spans projects to see the entire scope, if each project was its own repository, it seems it would be a pain to try to analyze *all* code changes across repositories?

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

Thanks in advance.

提前致谢。

采纳答案by Koby

The reason most people advise to do separate repositories is because it separates out changes and change sets. If someone makes a change to the client projects (which you say doesn't really effect others), there is no reason for someone to update the entire code base. They can simply just get the changes from the project(s) they care about.

大多数人建议做单独的存储库的原因是因为它将更改和更改集分开。如果有人对客户项目进行了更改（您说这不会真正影响其他人），那么某人没有理由更新整个代码库。他们可以简单地从他们关心的项目中获取更改。

Git Submodules are like Externals in Subversion. You can set up your git repositories so that each one is a separate layer, and then use submodules to include the projects that are needed in the various hierarchies you have.

Git 子模块就像 Subversion 中的 Externals。您可以设置您的 git 存储库，以便每个存储库都是一个单独的层，然后使用子模块来包含您拥有的各种层次结构中所需的项目。

So if for example:

所以如果例如：

/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

This ensures that any updates to the /Core repository are brought into UI Layer repository. It also means that if you have to update your shared libraries you don't have to do it across 5-6 projects.

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