Proper git workflow for this setup?

Question

So we have our template_site

This is basically the front end base for any sites we build.

we have our cms

This is the backend for the sites and resides in template_site/cms but is in it's own repository as we often use it without the template_site as well

We have our modules which have files that reside in

template_site/(all over the place) and cms/modules/(name of module)

Essentially what we want is to have
The cms in it's own repo,
The template_site in it's own repo. and then for every module we create have that as a branch off another repository. cms_modules but we only want that repository to contain the files and changes to files specific to the module, so that we can pull a module into an existing project and have it only affect those files.

The issue is that basically all sections are linked, but we want to be able to while working on a module pull in any changes to the template_site, and also pull in any changes to the cms

Reason for this setup is that, for each site we create we want to clone the template_site into it's own repository and then we can customize it as needed.

How can we do this?

Or is there a better workflow for this sort of setup?

What I can see as the appropriate setup for this would be:

Have the cms_modules repo as the "super project"
Have the master branch have no modules in it.
Add cms as a submodule
Add template_site as a submodule

That way we can clone the cms_modules repo into it's own repository and work off that and only init the template_site submodule if we need it. But the only issue I can see here is We would want the cms_modules copy (for new sites) or branch (for new modules) to track any new files at it's root, but also track any changes or new files inside the sub modules instead of having their respective repositories track them.

Then if there is an update to the template_site or cms repositories we can just cd into their respective directories and issue the updates, but again we would want the merges for any files we have changed to be tracked into the cms_modules repo not the respective submodule.

And if we want to add another module we can just merge in the branch for that module.

How could we set that up?

Answer 1

Repo structure: git submodules seems to be best-designed for situations in which you are using an external repository not under your control. The idea is that you are transplanting a different repository within your current repository, but part of the trick is that the state of a branch in the outer repository will contain a commit hash of the 'current version' of the submodule. In other words, the outer tree won't show progress in the inner tree without an additional commit to the outer tree. This makes a lot of sense for the external case--I don't want my build to be broken due to development in a library I use--but seems like a lot of bookkeeping in your case.

A more intuitive use of submodules would be if you were to create a whole new repository per site, and then have cms be a proper submodule of that. In that way, each site could interact with a different snapshot of the CMS folder, and you only push out a new version when you're ready.

Repository count: Because your data is actually under your control, it makes the most sense to me to have one repository. You could make a good argument for separate repositories if, for instance, one of the directories were large enough (in megabytes) or if a subset of your coworkers should only have access to one or the other, but otherwise, there's little advantage to keeping the repository parts separate.

Branch per module: I tend to agree with the Stack Overflow answer here that recommends against putting entirely different content in each branch. In that condition, unless you create merge commits automatically or frequently, there will be no single branch that contains multiple modules (or all of your modules). There's nothing in git that prevents it from working that way, but it's atypical.

My preferred branch structure: Create a master branch that contains all modules and all sites. You can still create a branch per module or site to ease development, but once the code looks good, merge the branch into the master. Haven't touched a module in a while? Delete the branch--you can always recreate it later.

Hope that helps!