Question

We have a custom built project “kickstart”

This kickstart can have modules added to it quite easily.

When we build these modules we build them all based on one clean master copy of the kickstart which is version controlled.

When we start a project we create an empty repo,
set up the kickstart repo as a remote,
Pull from the remote.
When there is an update to the core we again just pull in from the remote.

This works well.

But we have the modules I mentioned, we build them all on the clean kickstart as a new project.

We want to version control all these modules.

The files for the modules actually reside inside the template.

Our workflow looks something like this

/site 1
  /kickstart
    /module1
      /module1 files
    /module2
      /module2 files
  /site 1 specific file
  /site 1 specific file

/site2
  /kickstart
    /modification of kickstart file for site2 only (e.g. config.php)
    /module2
      /module2 files
    /module3
      /module3 files
  /site 2 specific file
  /site 2 specific file

/site3
  /kickstart
    /modification of kickstart file for site3 only (e.g. config.php)
    /module1
      /module1 files
    /module3
      /module3 files
  /site 3 specific file
  /site 3 specific file

So,
Sites 1,2, and 3 are their own git repositories.

They all contain kickstart which is a git repository

Some of them share modules.

Now we don’t push upstream from these, if we decide something works well while doing it in site 1 we will checkout the clean copy of kickstart and make the changes there and then they get pulled down into all the different sites.
The same thing with the modules.

But my basic question is, where do we put the modules?
They depend on the kickstart being there.

One idea was to have them as branches off kickstart, I have also heard of sub modules and sub trees but don’t know how they work.

What would the best way of structuring this workflow be?

Answer 1

Putting those three sites in their own Git repo (as opposed to using one repo with three branches), means you don’t have to do much (if any) merges between site1, 2 and 3: all 3 have only one remote: the kickstart repo.

Regarding module management, each module should be in its own repo in order to easily use submodules or subtree:

• submodules is a way to get each module individually, with its full history, in its own directory, allowing even to push back to each modules repos.
• subtree comes in two flavors: the 2007 subtree merge strategy (explained here), and the recent (1.7.11+) subtree command.
  The subtree merge strategy (see also here) would me more adapted to merge one of the modules repo into a sub-directory (modulex). Since you don’t need to push back, it might be your solution.