Over the past few weeks, I've been evaluating Git. I'm sure you have heard of it, but in case you haven't, I'll give it a quick run down. Git is the leading distributed version control system out there, mainly because it is what is used for the Linux kernel and Linus has been doing some pretty heavy promotion of it. I figured I would try it, seeing as I'm a sucker for things that are hyped (and Git has definitely gotten its fair share of hype lately from all over the blogosphere).
Installation
Git was pretty easy to install. I downloaded and compiled the source, and it went really well. There is also a
unofficial binary
available, if you're afraid of
make.
There aren't (to my knowledge) any nifty GUI tools for Git, or a Textmate bundle. But that hasn't bothered me much- I never used the Subversion equivalents. It always seemed faster to do it via the command line (while occasionally piping
svn diff
to Textmate).
Learning Curve
Overall, Git was really easy to understand. Setting up a repository and committing things locally is pretty much identical to Subversion. Setting up a remote repository and pushing to it was also pretty easy, and about on par with an svn+ssh setup. Getting Git to work with Capistrano was also surprisingly easy. It took about 20 minutes total to read up, install and start working with my basic Git setup.
Some bumps
I wanted to set up a
public-facing code repository
that would make it more likely that I would share some of my code. I figured that this would be a strong suit of Git since it is all about sharing and its decentralized nature means that pretty much every contributor is going to have their own publicly-available repository. However, I was sorely mistaken. The online FAQs for setting up this kind of repository over http were sparse, incorrect, or both. After 3 different tries and about two hours of work, I finally got one working. I'm still not sure if it is set up the right way, but at least
git clone
works, and that's what really matters.
Overall, this portion was a pain in the ass and it would be nice if using
git init
would work for a git repo over http. The confusing combination of
git init
and
git init-db
while apparently requiring
git update-server-info --force
for no reason makes this a big failure for Git. Maybe there's another explanation- maybe I'm retarded. I don't know. But setting up something that should have been easy was instead horribly difficult and poorly documented.
The Strong Suit: Branching
I will have to say, however, that branching a repository in Git is incredibly easy. It really is impressive how easy it is to create a branch and to switch between the two. This is useful even for only one developer, because I can maintain a "public" branch of some code. Now I can, for instance, keep my database.yml intact without publishing my database passwords to everyone. I don't even have to use nasty workarounds like database.yml.mine- I have my own branch that my own database.yml is checked in to. What a breath of fresh air.
Conclusions
Overall, Git is nothing revolutionary. There are some really nice features, and I'm sure some other big gains for large open source projects. But if you're working with your own code base or a small team, this won't change the way you work in any significant way. What's more is that I don't see any reason why the biggest advantages of Git (branching, local repositories) can't be included in Subversion or any other centralized version control system. The biggest obstacle is politics.
Still, I highly suggest that you switch to Git for all of your development if you can. The ease of branching and the local repositories alone are enough to warrant the 10 minutes of work it will take to switch from Subversion. Really- 10 minutes. That's all it will take.
That said, will I be switching to Git for all of my development? No. While all of my personal development has already switched to Git, for my day job I'm kind of tied to Trac. The ability to associate tickets with discrete versions in Trac is invaluable and actually required by law in our particular case. So until Trac or another equally good bug-tracking system supports Git, I'm sticking with Subversion for my day job.