传统n层设计中包含多个项目的Git存储库的最佳实践 [英] Best Practice for Git Repositories with multiple projects in traditional n-tier design

问题描述

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

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

然而，我还没有看到有人公然问的是，当你拥有传统的n层开发（UI，商业，数据，然后共享工具），其中每一层都是自己的项目，如果您使用一个或多个代表ositories？我不清楚，因为几乎总是，当添加新的功能时，代码更改会在每个图层中起波纹。

使复杂与Git有关的问题，我们已经在'框架'中复制了这些层，以便从开发人员的角度制作更多可管理的项目/组件。为了讨论的目的，我们可以称这些项目/图层集合为'塔希提岛'，它代表了一个完整的'产品'。

客户网站/项目的定制/扩大大溪地的补充。在一个文件夹结构中表示这可能是最好的样子：

  /客户
 /客户1 
 /客户2 
 
 / UI层
 / CoreWebsite（views / models / etc）
 / WebsiteHelper（包含适用于任何网站的'web'助手）
 /Tahiti.WebsiteHelpers（包含'web'助手只适用于Tahiti网站）
 
 / BusinessLayer（针对不同'框架'的逻辑项目）
 /Framework1.Business 
 /Framework2.Business 
 
 / DataLayer 
 /Framework1.Data 
 /Framework2.Data 
 
 /核心（项目/图层共享工具可用的项目）
 / SharedLib1 
 / SharedLib2 
  

在解释了我们如何扩展传统n层设计之后多个项目，我正在寻找任何有关类似情况做出什么决定的经验（即使是简单的用户界面，业务，数据分离都是您使用的），而且更容易/更困难。你的决定。在我的初步阅读中，我是否对子模块如何会有点痛苦？比值得的好处更痛苦？

我的直觉是对塔希提岛的一个资料库（除客户项目之外的所有项目）以及每个客户端的资料库。我猜测的整个大溪地来源必须是< 10k个文件。这是我的推理（我欢迎批评）

• 在我看来，在Git中你想跟踪'features'的历史与vs个人的项目/文件，甚至在我们的项目分离中，一个功能将始终跨越多个项目。 在核心站点编码的'功能'几乎总是影响最小核心网站和所有'框架'项目（即CoreWebsite，Framework1.Business，Framework1.Data）
  
• 功能可以轻松跨越多个框架（我会说10％的功能我们的实现将跨越框架 - CoreWebsite，Framework1.Business，Framework1.Data，Framework2.Business，Framework2.Data）
  
• 以类似的方式，一个功能可能需要更改1个或多个SharedLib项目和/或UI网站助手项目。


• 对客户自定义代码的更改几乎总是只在本地存储库中存在，不需要跟踪其他组件的更改以查看w假设一个特性跨越了整个范围的项目，如果每个项目都是它自己的存储库，似乎尝试一下会很痛苦分析存储库中所有*代码的变化情况

预先感谢您。

解决方案

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

Git Submodules就像Subversion中的Externals。你可以设置你的git仓库，这样每个仓库都是一个单独的图层，然后使用子模块来包含你拥有的各种层级所需的项目。

例如：

  / Core  - 它是包含它的基本文件的自己的git存储库（如您所概述的）
 / SharedLib1 
 / SharedLib2 
 
 / UI层 - 拥有git存储库
 / CoreWebsite 
 / WebsiteHelper 
 /Tahiti.WebsiteHelpers 
 / Core / Git子模块到/ Core存储库
 / SharedLib1 
 / SharedLib2 
  

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

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.

解决方案

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.

这篇关于传统n层设计中包含多个项目的Git存储库的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！