Advantages of a Git and Subversion blend

Using Git as a front-end to Subversion provides more comprehensive version control and flexibility in the way I work, especially for a laptop user. Everything is under active version control, with or without a connection to the remote Subversion repository.

Branching and merging is quick and simple, and as a result I find I do this far more often than when using Subversion alone. I also commit changes more frequently: it’s far quicker than using a remote repository, even when not off-line.

This sort of functionality is vital to successful version control, and I think it promotes better practice, as long as you’re only committing working software. All the local Git commits will later be bulk committed to the remote repository. However they all retain their identity as separate versions, so discipline is important, we wouldn’t want anyone finding broken code.

I could get all this from Git alone, but the combination retains Subversion vendor branching and the deployment advantages of my existing Subversion / Capistrano set up. I’m going to try GitHub, or my own remote Git repository, and exploiting the Capistrano support for Git, but at the moment why reinvent the wheel?

I prefer to work on the command line, and that’s the approach this series will take, but GUIs are available for Git, try typing git gui to check out the one bundled.

I use this approach for anything I need version controlled, including my Curriculum vitae/Resume, but before try this out for yourself you’re going to need to check out a local copy of that remote Subversion repository… I’ll cover that next time.