Moodle HQ use something similar for maintaining the code for all Moodle community sites (such as this moodle.org). Our model is slightly different from what the Open University uses and seems to work well for us, too.
Basically, we have a clone of moodle.git. In a certain and well defined point (best identified by some upstream tag), we create our own tag that acts as a base point for the whole site composition. Let us say this base tag is called ourmoodle-2.8-base
and it matches the commit tagged as v2.8.0
.
The basic idea of our model is that every single local hack/customization and every single additional plugin goes into its own "feature" branch. All these branches are created off the base tag. We have certain rules on naming these branches, which helps to administer it all.
Let us say there is a branch ourmoodle-2.8-theme
where the site theme plugin is committed (we commit just snapshots of additional plugins, they have their own development history in their native repositories) and another branch called ourmoodle-2.8-login-page-hack
with some customization.
We create a branch called ourmoodle-2.8-test
and we merge all feature branches ourmoodle-2.8-* as well as upstream MOODLE_28_STABLE branch to it.
This -test branch can be deployed on our notebooks and the test server and it helps us to be sure that we all share 100% same version of the code.
Once we are happy with testing, the -test branch is again merged to another ourmoodle-2.8-deploy
branch that is then deployed to the production site.
When a new 2.8 stable version is available, we simply merge MOODLE_28_STABLE into the ourmoodle-2.8-test
branch (and then, after testing the upgrade etc), we merge that into ourmoodle-2.8-deploy
again. This can be done easily for every weekly build, if we want to.
When doing the major version upgrade, say from 2.8 to 2.9 in this example, we principally use git rebase --onto
. We are aware of every single modification done in our 2.8 site (because they all are tracked on separate branches) so we can re-create ("replant") these feature branches in the new version. In other words, we create a new base tag ourmoodle-2.9-base
and we create a new branch ourmoodle-2.9-login-page-hack
from it. We know that all the commits in the range ourmoodle-2.8-base..ourmoodle-2.8-login-page-hack
need to be re-applied to this new branch. We usually use git-rebase, git-cherry-pick or git-format-patch && git-am to do that. If there is a conflict, we know that upstream has changed and we need to investigate further. Even if the patches apply without the conflict, testing is still needed as there might be some change elsewhere that does not allow the customization work any more.