26

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 ?

DilithiumMatrix
  • 17,795
  • 22
  • 77
  • 119
FMaz008
  • 11,161
  • 19
  • 68
  • 100

2 Answers2

16

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.

Susanne Oberhauser
  • 413
  • 6
  • 13
John Douthat
  • 40,711
  • 10
  • 69
  • 66
  • Well, I've read the git help submodule and they say: "They are not to be confused with remotes, which are meant mainly for branches of the same project; submodules are meant for different projects you would like to make part of your source tree, while the history of the two projects still stays completely independent and you cannot modify the contents of the submodule from within the main project." ... in my case I'll want to modify the submodule inside the client project in case I'd need to personalize a plugin. Now you're telling me that we can modify submodules ? – FMaz008 Mar 27 '11 at 11:39
  • 1
    yes. Modify the client's plugin code, commit and push the changes to (2), then go to the client's CMS code, and commit and push the change to the plugin (updates the SHA hash) to (1). – John Douthat Mar 27 '11 at 23:19
  • Ok, sound like a good answer, but I still have 1 complementary question concerning the folder organization/structure: http://stackoverflow.com/questions/5461617/using-git-and-submodule-whats-a-good-folder-structure – FMaz008 Mar 28 '11 at 15:50
9

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

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.

Guildenstern
  • 2,179
  • 1
  • 17
  • 39
Maxime Brehin
  • 377
  • 6
  • 4
  • Updated documentation [git-scm book](https://git-scm.com/book/en/v2/Git-Tools-Submodules) – sbkm Oct 16 '22 at 13:37