There are many frustrating ways of writing and testing web designs. When updating my site to use WordPress as a familiar CMS rather than editing my HTML directly (which has its charm) I decided to try something I'd heard a lot about but didn't understand: sub-versioning.

I haven't ironed out all the issues or even full understand what I'm doing yet, but I can see the power of such a system and why it's so popular with development teams.

Before I had much reason to pay for server space I did most of my web experiments on my PC, running a local server. Upon entering the fantastic Mac ecosystem I transitioned my development workflow to the excellent one-click MAMP.

My first frustrations with running a local server crept up when I was trying to do some IMAP server queries with PHP. The libraries weren't installed on my development machine but they were present on my clients production server. I spent a good Sunday afternoon indoors compiling all the dependancies to get this library to work.

While it was most satisfying to get this to work, I yearned for an easier way to develop.

Up until recently I've been using a much more satisfying combination of TextMate, Cyberduck and Google Chrome or Firefox + Firebug. Cyberduck has the handy feature of automatically uploading changes made to files that are downloaded. Essentially I was modifying files directly on my production server.

Any developer will be able to tell me what is wrong with this picture.

Most of the time I worked in testing directories, invisible to the causal visitor, but any slip-ups with a .htaccess file or a misplaced resource could kill my entire site.

The other issue with this workflow came when I started taking my laptop with me everywhere so I could develop on the go. While tethering works great and the upload latency for a single file isn't impeding, if I was somewhere without reception (City Circle train tunnels) or my service was down I was stuck without being able to work.

Recently, for a few stressful hours, my web host was inexplicably down. While they resolved the issue quickly once I contacted them about it, I was again stuck without being able to work.

My primary tool, TextMate hasn't been updated for a while causing syntax-highlighting issues with the latest versions of CSS and HTML. It also doesn't support auto-complete, which I've never seen as a huge issue. I've learnt to think for myself when typing selectors and functions.

I've seen a lot of good press about Coda and was keen to give it a go. Panic hasn't updated Coda for a while either, so while it supports some newer properties that TextMate doesn't, there is still enough missing to make this software feel a bit dated.

My initial expectation was that I may use a version control system with Coda, which it is capable of but only supports the dated SVN system.

Coda makes it easier to edit files on an FTP server, just as I had been doing with the TextMate + Cyberduck combination. A file browser is pinned to the left of the edit window, supporting drag and drop uploads from finder along with click-to-edit.

Coda integrates a webkit browser for previewing edits, and while it works well, it lacks an extensive javascript debugger and DOM explorer which is vital for developing complex client-side programming.

I still wanted to avoid working on files directly on my production server, and this is where I believed a sub-versioning system would step in.

GIT is well regarded as a modern sub-version system.
Originally I believed GIT would magically synchronise my development machines and hold on to revisions automatically.
It only partially does the latter.

GIT is designed to allow its users to decide when a revision is made before adding it to the repository master.

The main component I've been working on recently is my WordPress theme, so as an experiment I turned the themes directory into a GIT repository.

Using the command line tool I downloaded the directory as it stood on my server so changes I made on my local machine can be pushed back to my production server.

This means that I was back on the local testing workflow. Throwing together PHP support and a MySQL server to hook into the built-in Mac OS X web sharing Apache server, I installed WordPress. Once I began using both my laptop and desktop machines for developing the theme I discovered this was a brilliant method of development.

When I was developing on my own production server, I relied on the existence of libraries, frameworks and paths that were required to exist and be in a predictable place. This doesn't make for very portable code.

It took me a while to find a use for Dropbox as most of my media files are large and can only realistically be backed up locally. While working on web layouts for a client I received mockup files from my design collaborator and worked on the code between my laptop and desktop. Dropbox effortlessly kept the required files handy wherever I was.

Dropbox works amazingly well with GIT to fill my expectation void of a synchronised development between machines.

Using symbolic links to access the web sharing folders in Dropbox, I maintained a perfect copy of the themes git repository I was working on between my laptop and desktop. Each machine with its own WordPress install and different test content.

The power of such a set up is being forced to test code portability.

I'll keep working with GIT and discover more about how it can help me track revisions of my code. For now, a quick push to my production server gave me a brand new theme ready for instant activation.

I feel more like a real developer.