My DrupalCamp Toronto Session: How is Git Being Used for Revision Control?
Topics:
As I've done a lot of DevOps work in the last few years, and have been using Git for quite a long time (before drupal.org in fact), I've given a couple of talks on it. I ran an introductory session at DrupalCamp Toronto 2011. Two years later, I ran another one recently at DrupalCamp Toronto 2013. I didn't spend too much time on teaching the basics as by now, Git is fairly common. I talked about some different high-level approaches to using Git for managing Drupal projects. I was also interested in which methods were being used.
The different approaches I talked about were:
- The vanilla install-all-Drupal-files-in-a-single-repository approach
- The Drush makefiles approach
- The MR with Drupal approach
- The Git submodules approach
What I discovered was that just about everyone went with the first method. This is fairly standard approach, but it's not without its problems. I don't like how you lose upstream history in contributed modules, and it's challenging to merge your local customizations with upgrades without losing them.
Some folks had heard of Drush makefiles (but just a handful), and were actually using them. The problem with this one is that it takes time to rebuild your site every time you make a makefile change. And with continuous integration solutions, this puts a lot of pressure on your servers. The good new with this one, though, is that you get an explicit recipe for your site.
I mentioned the MR method because it's out there, but I haven't heard of anyone other than Wim Leers using it. I only know about it because he reported on it. Basically, it's similar in concept to using Drush makefiles, but it's not a Drupal-specific solution.
Now the fourth approach, Git submodules, which I happen to like, didn't appear to be very popular. Nobody at the session was using it. This is unfortunate because it solves the upstream merging problem very well. The tricky part here is getting your developers to understand the extra moving parts on top of the standard Git complexity. But with a little bit of education, I think we can go far with this one.
At DrupalCamp Montréal in October, I'm planning to run another session where I run through the details of actually using Git submodules in a Drupal project. Ideally, we can come up with some best practices around it. In another two years, maybe then everyone will be using it.