Drupal and git


Here at Liip we use Git for version control on almost all our projects. So this post is not about why we chose Git over any other VCSs but how we use it to develop Drupal projects.
The main challenge when using Git in Drupal is how to incorporate Drupal modules. You could decide to drop them directly in your base Git repository, as a first step it would be really easy. But you would then lose all their history, and maintenance would be quite painful: want to test a new branch or tag and then go back to the old situation? Possible, but if you have further commits on top of it, it could become quite tricky.


That’s where git submodules come in: using them allow you to leave each module in its own repository which has multiple avantages: you keep their history untouched, can easily change branch or tag and go back if needed, merge any new release, etc..
In Drupal 6 the setup was quite painful, as modules creators/maintainers were not using Git themselves. At Liip, we used to create Git repos and drop the files in. This means that you lose most of the submodules power but at least all modules can be tracked separately and any change would be Git versioned. But now with Drupal 7 it’s much easier: all modules are in Git already so all you have to do is point to their remote origin and start enjoying them! (see the resources at the end for more on the ‘how’ side).


If we need to make any change/fix on an external module we would clone it, create a new branch (or not, depending on the amount of changes), do the updates, add a new remote (either on github or on our own Git repository server), push the changes there and offer the Drupal module maintainer to review and possibly integrate the changes.
Your submodule is now pointing to another remote, so your co-workers will have to use the git ‘submodule sync’ command to update their copy.


Git submodules make it really easy to track modules’ lifecycle and is a key part of the way we do Drupal at Liip (along with Debian packages for deployment and Drush+Features for scripting). And with Drupal move to Git you have no more excuse not to use them!


Want to get more into technical details? check our FOSSwiki
More on git submodules in the git book


Thx, good blogpost. Don’t know if you’re aware of, but since it wasn’t mentioned in the post: for doing adaptions on a module githubs fork and pullRequest functionality could be quite useful.

right Alain, though original drupal modules are usually not hosted on github…

I´ve not yet worked with Drupal – only with Contao CMS. Some of our clients have already Drupal installed, so I will give it a try!

I used to employ git-submodules a lot for the exact same purpose, i.e. pulling in contrib modules from drupal.org into sites/all/modules. Before the recent switch from CVS to git on d.o I had a script parsing the release history of selected projects and commiting new releases automatically to my repositories. I was then able to upgrade a module
using a simple git pull in the checked out submodule and committing+pushing it within the enclosing site.

However I abandoned the usage of git submodules recently because it caused too much confusion among colleagues. Having everything in one repository also simplifies deployment, especially when git or shell-access does not happen to be available on a target host (via git-archive). Note that it is no problem to still maintain some modules as a git
checkout locally. You may even add changed files from the git checkout to the main repository while keeping the exact history in a branch in the modules repository. Like that, submitting patches upstream remains straight forward.

For site maintenance I simply rely on drush.

For Drupal Modules we are always using GIT. At today we are working on a Connect for Drupal and Shopware, and some more Shop-Systems.

Connect for Druapl and Shopware? Sounds very interesting. Some details to share already? Thanks

It is indeed my great delight to Think About your website Also fantastic to appreciate your current content right here

I can not stop reading this. And ‘so fresh, so full of information, I do not know. I’m glad that people actually write the smart way to show the different sides of him.

This post is exactly what I am interested. we need some more good information. Please add more good information that would help others in such good way.