Hi there, and welcome to the first of my bi-annual blog entries. ;)
Today, ladies and you oh so gentle men, we'll be looking at something very exciting, something very hip, something so edgy it could be called bleeding. Yes. We're talking Git. We're talking a new VCS paradigm. We're talking Drupal, and we're talking managing Drupal sites.
First and foremost, this is the tale of how I set up freso.dk to have its code managed by Git.
In yon olden days, freso.dk was managed by CVS checkouts. These CVS checkouts were then added to a Subversion repository that'd keep track of them all. This meant that everytime I
cvs up'ed, I would have to manually
svn rm and
svn add gone and new files. It also meant that there had to be a source repos somewhere, that I would have to have access to at all times where I wanted to work on the site.
This wasn't something that I found very fluid nor easy to work with. At this point, I had already been looking at Git to replace Subversion for a while, but never gotten around to it. Subversion was familiar and something I have worked with before, Git was uncharted territory. Not only a new system, but a completely new way to handle versioning.
The Drupal community has also been unsatisifed with CVS for quite some time, and what should eventually be the replacement of it had been the subjection for discussion. And more discussion. And the discussion was discussed. And then some new discussion. The result? It finally landed on Git! Yes, all the code in drupal.org's CVS repository are now, as we speak (or I write, you read), available in Git repositories!
So, to stay on the edge, I decided to go ahead and move freso.dk to be managed by Git on the very same day of this change. Here's what I did.
Warning! Remember to back up your site before trying to do any of this at home, kids! Also beware of losing translation files, local changes, etc.
cvs diff is your friend.
I keep the files of my site locally and push them to the server when they're updated, so let's start by moving the old directory aside.
# www> mv freso.dk freso.dk-cvs
Now we need a new directory to keep the files in. But hey, this directory is the repository! So let's clone Drupal core:
# www> git clone --branch 6.x http://git.drupal.org/project/drupal.git freso\.dk
I now have a new directory "freso.dk" containing a check-out of the branch "6.x" from Drupal's Git repos. I don't want to mess around with the core though, so to keep this pristine, let's make some new branches for running the site:
# www> cd freso.dk
# freso.dk> git branch -t 6.x+contrib 6.x
# freso.dk> git branch -t freso.dk 6.x+contrib
Now there are three branches I need to worry about: 6.x, which is Drupal's core; 6.x+contrib, which additionally has various contrib modules etc. on top of it; and freso.dk which will also have certain site specific changes (e.g., to .htaccess etc.).
Let's populate the contrib branch:
# freso.dk> git checkout 6.x+contrib
# freso.dk> move-drupal-contrib.sh ../freso.dk-cvs
First the branch is being checked out, then I run a little script of mine. It basically runs through the old dir's sites/all and runs
git submodule add for each project it finds. (Feel free to expand on it, the code's in my (Git) sandbox and patches are accepted.)
Alright, so the site is now populated with modules. But what version? All the modules have been submodule add'ed to their master branch, so here's a bit of a manual part. I went to admin/reports/updates and went through the list, using
git checkout to the currently installed version on all the module folders. Then I finished off by
git commit -a in the root folder. Be sure that all of your installed/enabled modules are on a useable version, it might cause trouble if you, for example, have a 7.x module on a 6.x site...
Before I go on with the site specific changes, let's add one module first: Git deploy. It doesn't have any releases, so I'm living on the edge and adding the -dev version:
# freso.dk> git submodule add --branch 6.x-1.x git.drupal.org:project/git_deploy.git sites/all/modules/git_deploy
# freso.dk> git commit -a -m "Added git_deploy module at 6.x-1.x."
Now, let's look at some of the site specific stuff.
# freso.dk> git checkout freso.dk
# freso.dk> git pull
After copying over changed and site specific files (.htaccess, robots.txt, settings.php, etc.) from the old directory and committed these, we're now almost there! First, let me comment on the settings.php. Don't store your password in the VCS. Not unless you're sure that nobody else will ever have access to it. I've simply removed the
$db_url = '...' line and replaced it with
require_once('db_url.php'). "db_url.php" then simply contains the
$db_url line, while also being mentioned in the .gitignore (which also has an entry for files/). That way I can track settings.php without worrying about my database password accidentally slipping out, should I ever share access to the repos with anybody. :)
Now, once you've double and triple checked that all the files you want (and need!) are there, upload it all to your server, removing old CVS and Svn cruft, and head straight for admin/build/modules - disabling CVS Deploy, enabling Git Deploy. (Notice that for 6.x, Git Deploy requires the Libraries module for discovery of the Glip 3rd party library - which it also requires.) (Also, at this point my theme, Garland with color, decided to stop working, the solution was to fiddle with the colour wheel and so it reset.)
After you've switched the deploy modules, let's go back to the terminal to remove CVS Deploy. Unfortunately, there's no "git submodule rm", so we need to hack a bit:
# freso.dk> git checkout 6.x+contrib
# freso.dk> sed --in-place '/cvs_deploy/d' .gitmodules
# freso.dk> sed --in-place '/cvs_deploy/d' .git/config
# freso.dk> git rm --cached sites/all/modules/cvs_deploy
# freso.dk> git commit -a
# freso.dk> rm -rf sites/all/modules/cvs_deploy
The sed commands delete the lines containing "cvs_deploy", with the "--in-place" option telling sed to work directly on the file, instead of printing to stdout.
Once all that is done.. we're ready to test the site. Once the testing's satisfactory, let's upload the files to the server and enjoy the new workflow. :D
ps. Remember to Google/search for any thing you might want to do with Git. A lot of people have written a lot of easily digestable materials on how to use it - don't let their work be for naught! :)