Git子模块或子库或远程？

问题描述

我正在使用GIT来管理内容管理系统（CMS）项目。 CMS可以有多个插件（模块）。

因此，基本上我想要有3种类型的存储库：

• 核心CMS开发（每个新项目都是最后一个稳定版和未配置版本的结账）
  
• 每个模块/插件1个存储库。 （每个新项目都会签出他们想要实现的模块的最后一个稳定版本）。
  
• 每个项目有一个存储库（每个客户端将是一个代表核心CMS和模块）

对于1& 2，我想这是简单的基本知识库。
但是当它来到客户端项目时，我感到困惑：

• 首先，我将克隆CMS，然后进入/ modules /文件夹并再次克隆所有需要的模块？这将在存储库中创建一个存储库！第一个repo会尝试记录每个模块的.git /文件夹吗？
  
• 我无法使用子模块，因为每个客户端都需要对其模块进行个性化设置。


• 如果我修改模块的核心组件（不是个性化，只是一个错误修复），我可以将该单个文件推送到原始模块存储库吗？


• 谈论模块unitTest将散布在四周）

所以问题是：
如何组织仓库（s）/ files / folders为了高效？

解决方案

子模块。我会轻轻推荐阅读并尝试一些。您的计划引入的主要区别是每个客户端存储库和客户端插件存储库都有两个远程控制器，而不是一个。而且，当你想开始一个新的客户项目时，你需要

1. 分支主线cms


2. 分离所有将被修改的插件
   
3. 克隆来自（1）的分叉cms，更新其子模块以指向来自（2）的新遥控器


4. 初始化/更新子模块


5. （可选）将主线cms URL添加为远程客户端的分叉cms


6. （可选）将主线插件URL作为远程客户端的分叉插件添加

更好的选择可能是使用同一个存储库，分行每客户。这就是我要做的。

I'm using GIT to manage a Content Management System (CMS) project. The CMS can have multiple plugin (module).

So basically, I want to have 3 types of repositories:

• The core CMS development ( every new project is a checkout of that last stable & unconfigured version )
• 1 repository per module/plugin. ( every new project will checkout the last stable version of the module they want to implement )
• 1 repository per project ( each client will be a repository that represent the personalization from the core CMS and the modules )

For the type 1 & 2, I guess it's simple basic repository.But when it come to client project, I get confused:

• First I'll clone the CMS, then go in the /modules/ folder and clone again all required modules ? That will make a repository inside a repository ! Will the first repo will try to log the .git/ folder of each module ?
• I can't use submodule as each client needs their modules to be personalized.
• If I modify a core component of a module ( not a personalization, just a bug fix ), can I push that single file to the original module repository ?
• (Not talking of the module unitTest that will be spread all around )

So the question is:How should I organize the repository(s) / files / folders in order to be efficient ?

解决方案

The layout you've described will work really well with git submodules. I'd gently recommend reading the docs and trying a few tutorials. The key difference your plan introduces is that each client repository and client plugin repository will have two remotes instead of one. And, when you want to start a new client project you will need to

1. fork the mainline cms
2. fork all of the plugins that will be modified
3. clone the forked cms from (1), update its submodules to point to the new remotes from (2)
4. initialize/update the submodules
5. (optional) add the mainline cms URL as a remote in your client's forked cms
6. (optional) add the mainline plugin URLs as remotes in your client's forked plugins

A better option may be to use the same repository and simply make a branch per client. That is how I would do it.

这篇关于Git子模块或子库或远程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！