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

发布于 2024-10-29 07:00:00 字数 1906 浏览 6 评论 0原文

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

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

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

为了使 Git 的问题变得复杂，我们在“框架”中复制了这些层，以便从开发人员的角度来看更易于管理的项目/组件。为了讨论的目的，我们将这些项目/层的集合称为“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 源必须小于 10k 个文件。这是我的推理（我欢迎批评）

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

提前致谢。

原文

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.

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.

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.

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'.

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?

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)

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?

Thanks in advance.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

眼前雾蒙蒙 2024-11-05 07:00:00

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

Git 子模块就像 Subversion 中的外部。您可以设置 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 层存储库。这也意味着，如果您必须更新共享库，则不必在 5-6 个项目中执行此操作。

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.

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.

回复收藏 0 原文