Submitted by Pixel Chimp on Tue, 22/07/2008 - 10:00

My experience using Git with Drupal

For me Git works pretty well with Drupal. Prior to trying Git I was using SVN with SVN-X to manage revisions. It worked ok, but there were several occasions that I broke the repository, by accidentally deleting a hidden .svn folder, and then attempts to fix it went wrong and it became unsalvagable. I expect it was due to being new to version control, but it always stuck me as painful having countless .svn folders cluttering up my working copy. I also had another collection of ‘virtual host’ settings to manage to be able to test the svn-export prior to syncing with the server - UGH!

Git is another version control system, named after the Linux git himself. It has some advantages over SVN or CVS…
Besides all the advantages of Git listed elsewhere (distributed repositories, easy branching) there are a few points that make it work well with Drupal, or just managing website or project versions.

Only one hidden folder

Git doesn’t have invisible .svn folders that make upgrading a pain, and ruin the repository if you delete one accidentally when syncing with the server, or updating a module. Git just has one folder called .git at the root of the repo that is created by git init

Clean working copies to sync to the server

There is no need to do SVN exports to sync to the live server - your working copy has one invisible .git folder in the root, everything else can go on the server as normal. Your working copy is always inside the same folder, no need to move things around to keep local virtual hosts working (to be able to use clean-urls on local test sites). This make branching dead easy and quick.

Simple branching

When checking out a new branch everything still works, Git switches the contents of the working folder to become whatever version you checked out. Great for making CSS modifications that can be merged back into the main branch when completed. One problem with this is that the DB may get out of sync between branches if you add & remove modules. All of the DB contents DO NOT GET SAVED BY Git, but there are some hooks to fire off scripts (on commit, on post commit etc) that could probably read the DB settings in settings.php and dump it into the git working copy and commit it. I haven’t looked into this fully yet, since it works fine as is. You would also need to revert the DB when checking out another version. It’s generally fine so long as you are aware making major changes to the DB will affect any other branches that use the same DB settings.

Gittish quirks

Git compares the content of files not just by using filenames, so moving stuff around seems ok, if a new item has the same content Git uses the same blob in the Git DB. The way you commit is by adding to an index, with a git add command then the items in the index are saved to the repository on commit. When you add items to the index Git creates the blobs, so you may have stale content if you git add, and then edit the files and forget to redo the git add before commiting. You can see the index via git status.

There are no real GUIs for Git on the mac like the SVN-X or Versions, but you can open some weird Git tools such as … gitk This opens the ‘Wish shell’ which shows the history as a tree adding –all shows stuff you have ‘pulled’ from in other repos & branches.

Wish shell tree listing

git citool Opens an editor to allow you to see the items to be committed and you can move them in and out of the index and make commits via the GUI. The Git TextMate bundle allows you to commit, checkout, see the log, revert etc all from within TextMate, handy but knowing the command line options always helps. For the most part things can be managed easily from the command line.

Git with Drupal

Git can ‘pull’ files from other GiIT repositories. So with Drupal you set can up several repos and then you can use Git to pull changes into other repos when its time to update. I have the following repos:

  1. Drupal base - just the clean download of Drupal
  2. Drupal and modules - a ‘clone’ of repo 1 with my favorite modules installed.
  3. Production site - a clone of repo 2 that has all the custom edits & modules in the production sites. This has an entry for an Apache virtual host so that it can be accessed using clean URLs. Its the only repository to actually be tested in the browser.

3 is where you do the work on the site, and sync to the server. When it’s time to update a module you check if its kept in repo 2, if it is replace it there, & commit it, otherwise just replace the module in the production sites folder. To update the site change to the correct repo and do a git pull to retrieve the updated module. ‘git pull’ sucks in the changes and commits remote (ones you have pulled from) repos, git fetch will get the changes but not commit them, so you can see changes first. Upgrading Drupal is the same except you update it in repo 1 and commit. You can then pull it into the other repos too.

Git with SVN and CVS

You can also import from existing CVS and SVN repos too, and some smart arse has created a repository of the entire Drupal tree. You could clone this and update by simply doing a git fetch and checking out the version you want e.g. git checkout DRUPAL-5.7. I guess you can do the same for the contributed modules too, but you would need to do the CVS-Git imports for every contributed module. So far it’s been great, With a little Google foo you can tame the Git and look after many Drupal sites easily.


Still working for you?

Submitted by Anonymous on Wed, 26/05/2010 - 21:05.

I’m curious if this is still working for you? Have you added any hooks for DB management?

What do you do to move your changes to staging/prod?

I’m still using this…

Submitted by Pixel Chimp on Tue, 08/06/2010 - 23:09.

GIT is still being used for managing my source code for Drupal sites. I looked into using GIT to store the DB contents, but that would involve extra complexity and I couldn’t handle the prospect of managing diffs of the database dumps.

I have made my a site use GIT for transferring changes between the test & live server. It works smoothly provided you make sure you fix conflicts on the test server.

I used this post at as a starting point.

I think that newer modules are making it more feasible to manage ‘settings as code’, check out Chaos Tools, Features, Context modules. Lullabot has an article that is worth checking out.

Drush is another helpful tool that also has the ability to rsync files back to the live server, which is similar to using GIT to push changes live.