Recommended workflow for multiple modules (themes)

Question

I have an app (cms) which structure is like this:

BASE:
    /application/
    /public/
        themes/
           default/
           mobile/

This is a base, central repository for all our projects. Then the projects get their own skin: (which are based on /default/ theme)

CLONE1:
    /application/
    /public/
        themes/
           default/
           mobile/
           own/
           ...
           own-theme-12/

(this app has 12 custom themes based on the default one).

The whole thing is about maintaining the applications and keeping all the CLONES up to date with the BASE.

Now, we add BASE as remote repo:

(/clone1/)$ git remote add base-repo /path/to/base.git

Then pull for updates when needed:

(/clone1/)$ git pull base-repo develop

When the .php files in /application are modified everything works great. The problem begins when we modify the files in default theme in BASE repo (e.g. typo in reset.css). We need those changes in CLONE1/default theme and all of the CLONEx/own-x/ themes.

Of course some bash script will be needed to tell where to copy and commit the changes, but how to keep the whole thing in sync without merge conflicts?

We use git flow. The default and mobile themes are not in the separate branches by now. Do we need them to be? We don't use submodules yet.

There are many ways to organize this workflow, but which would you choose as the optimal one?

similar question: http://stackoverflow.com/questions/3223922/git-workflow-for-custom-css-files-and-themes — takeshin, Jan 18 '11 at 10:34

score 2 · Accepted Answer · answered Feb 25 '11 at 12:08

You can use git-subtree to help with this sort of problem. Basically, what you're doing is building a custom app based on an upstream app, and your custom app has two kinds of changes: app fixes and special themes. You want to take the app fixes and send them upstream, but you don't want to send your special themes upstream.

If you create two subtrees at the toplevel: one for your upstream app, and one for your themes, you can then split/join them with git-subtree. The themes inherited from the upstream can be symlinked from the app directory into the themes dir. So you get something like this:

    /app/code/*.php
    /app/themes/default/
    /app/themes/mobile/
    /themes/default -> ../app/themes/default
    /themes/mobile -> ../app/themes/mobile
    /themes/own-1/

When you want to send app changes upstream, you do something like

    git subtree split --prefix=app --rejoin

score 1 · Answer 2 · edited May 23 '17 at 09:58

Considering the application needs those theme directories to function, they should be kept as directory, not as branches.
You cannot deploy several branches into production (you select version from one branch or another, not all of them). You can deploy multiple directories, allowing the application to run without having any knowledge about an SCM.

For the rest, a script executed as a merge driver could:

merge the content of BASE/default to local/default
check if the same file (like reset.css exists in other directories and start reporting the same evolutions on it as well).

I don't have specifics on the exact mechanism, but I suspect a merge driver is a good entry point to propagate the changes.

Recommended workflow for multiple modules (themes)

2 Answers2