What Git does best.

I run several remote Subversion repositories and connect using SSH over the Internet. Having local version control for those times I don’t have an ADSL connection was the main reason I looked at Git.

There’s a good TextMate bundle to support Git, but to be honest I’ve mostly used the command-line.

Weaknesses.

Vendor branching is possible, but awkward. I frequently use vendor drops of WordPress, SimpleTest and a number of other libraries. There may be a good way of doing this, but I haven’t found it online… yet.

I miss the svn:externals functionality, especially in applications that use a lot of plugins: WordPress in particular. Subversion allows me to define particular tagged versions of these to be pulled from their repositories during deployment without needing to bother controlling them myself.

Strengths.

Branch merging when trying out new ideas is a dream. I created a new branch, refactored huge sections of the codebase, and merged it all back together flawlessly. With Subversion this would have been a lot slower and more problematic. Git’s simply great for those investigatory spikes.

The verdict for Git.

I’ve yet to seriously try Git to interface with my remote Subversion repositories, using the ‘git svn’ series of commands. Having local copies of these, whilst still being able to use remote Subversion would be very useful. I’ve found using remote Subversion repositories easy, but trying to push a Git repository to Subversion is not so easy. I’m also going to try deploying from a Git repository using Capistrano in the near future.

It strikes me that Git is best at programmer related activities and weakest in those of interest to administrators deploying applications. I shall certainly continue to use it, but alongside Subversion.