This tutorial, if it can be called such, presupposes two things: you see some value in version control of your blog,¹ and that you’re relatively comfortable in the shell. I’m not going to make any effort to persuade you that this is worth your time, and I’m not going to make any effort to teach you how to use git. There are lots of great tutorials, written by people much smarter than I, which will do just that.

Whether it will be useful for your workflow will depend on your workflow. If you only ever write posts in a web-based post editor, it’s almost certainly useless to you; it will only work if you write locally, using a text editor of some description, and save it locally. It works to a certain extent if you work on files in your Dropbox, but you’ll still need access to your computer to carry out the commits (unless you use the script below).

Another, easier, option for Mac users is to use iCloud and Mac OS X’s built in versioning. I avoid this option personally because it doesn’t give me the control I want and because, conceptually, I’m inured to a files-in-directories mindset. For my own comfort, I need to know where the files are; “they’re in iCloud” is too nebulous and fuzzy a concept for my mind to comfortably grasp.

Setting up a git repository for your blog posts is the same as for your programming work:

1. cd into the appropriate directory;
2. git init;
3. git add --all (this is the lazy way of doing it, and saves the hassle of adding each file individually);
4. git commit -am 'LOL first commit OMFGBBQ'.

Any subsequent changes, additions, or deletions are handled in the usual manner.

This process can be slightly inconvenient if you don’t use a shell text-editor. One way around this is this very kludgey shell script²:

#!/bin/bash 

cd ~/Documents/Blog;
git add --all;
git commit -am 'Automated commit';

I’m almost certain that the above script is a clumsy way of doing this, and there’s probably a way to automate the description to include details of the files changed. The script is also hosted on Github, so you can fork it if you want to, or grab it from there. Alternatively, free to e-mail me to tell me I’m an idiot and explain how I should have done it.

The major downside of this script is that you’ll commit without any premeditation or thought behind it, and your commits have no meaningful description listed — just “Automated git commit” for each and every one. As a result, it makes useful version control much harder. The other potential downside is that it adds everything (--all) in that directory tree every time it runs; it can be mitigated with a few tweaks to your .gitignore_global file.

The overall usefulness of version control for a blog’s posts is probably questionable at best, and may not be worth the effort it requires to implement. It’s likely that roll-backs to earlier versions will never be required, but having the option is never a bad thing. In the year or so I’ve been doing it, I’ve rolled-back twice, but found the real benefit is the discipline it enforces on my otherwise chaotic workflow. More than that, it’s a worthwhile habit, and one I wish I’d cultivated earlier: if I had, I wouldn’t have fallen victim to the major versioning problems I suffered during my last huge project of typesetting a book.