Git子模块或子存储库还是远程？

Question

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 ?

Answer 1

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.

Answer 2

Short update / additional information about the previous answer: if you don't like git submodules approach or think this is too hard to understand, you can try

• git subtrees (check this article on medium )
• or git subrepo (easier alternative to submodules, on Github )
• or even dive deeper in submodules with " Mastering Git submodules " on medium.com

Don't forget to check if you can use another depency manager (like RubyGems for Ruby, Composer for PHP...) instead of submodules, it would be easier to use and maintain.