Monday 5 May 2008
It must have been months ago that I watched Linus Torvalds' presentation on Git. At that time, I remember thinking it probably wasn't for me. I already had a source control system that worked and did everything I wanted. I generally worked on projects on my own, and didn't need to worry about how long it took to merge other people's changes. Git was supposed to be better at branching, but I never branched my code anyway. Git had a distributed model, but the centralised approach worked fine for me. People were saying that Git was harder to use. Etc.
If I think back to before I started using source control a few years ago, I had a whole set of reasons for why I didn't need it. I largely wrote code on my own. I kept copious backups. A lot of my source code was stored in binary format RealBasic project files that couldn't be diffed. I didn't see why I should have to keep fiddling with the terminal every time I changed something. Excuses, excuses.
Of course, source control is one of those things that you find impossible to live without as soon as you start using them, and all the excuses I'd made became unimportant overnight once I got began using SVN. Starting to use source control was a revelation: things that were fiddly became easy, and things that were time consuming became things the computer did for me.
After a fair amount of prevaricating, I've made the jump to Git for several larger projects. This switch has been a revelation too, albeit a smaller one than starting to use source control.
Unless you're the smartest and most organised person on the world (in which case, what are you doing reading this?) or are currently in higher education, you probably have limited time available to learn new things. Why should you devote time to learning Git, over and above say, playing GTA? I'll note a few reasons why you should give Git a go, with a emphasis on migrating from Subversion, since that's the way I came in. However, it's worth noting that fair few of the things I find so compelling about Git are features of other modern SCM systems too, so do shop around for the best deal.
Why do I want Git?
Apart from a really cool name, Git has lots of great things going for it. A couple of the obvious ones:
- Every checkout is a complete repository, so you can still commit, revert and explore the history of a project, even when you're offline
- De-centralised design means you can push batches of commits to another checkout (eg a repository that other developers publish their changes to) whenever you like
- It's very, very fast, compared to SVN at least. If this doesn't sound like a big deal, wait till you've been using Git for a couple of weeks - you'll be amazed at how much time you spent waiting for subversion.
- Git keeps all its files in a single hidden (.git) directory at the top of your source tree, so you don't have .svn folders hiding all over your source
- Git is used to manage the Linux Kernel, and Ruby on Rails, so people a great deal smarter than me think it's the bee's knees too!
- Git makes branching really easy
Hold on: I don't need Git because I never do branching!
Chances are, you never do branching because your source control system makes it hard. Branches in git are super-easy and super-quick to do:
Show the list of branches
$ git branch
Make a new branch and switch to it
$ git branch mybranch $ git checkout mybranch
$ git commit -a
Switch back to main branch
$ git checkout master
Merge mybranch into main
$ git merge mybranch
There's no fiddling about with branch paths, and git won't waste time and disk space duplicating all the stuff in trunk so you won't have to clean it up later. The fundamental difference between Git and SVN in this regard is that Git 'knows' about branches, while branches in SVN are simply a pattern you use in laying out your repository structure. With SVN as each branch is simply an 'svn copy' of an existing directory.(i) Git shields you from the details, so there's no need to bother with trunk/tags/branches folders ever again.
The fact that Git makes branching easy is a lot more important than it might sound. You'll find you start to make temporary branches as part of your day to day work - experiments to try things out. This helps remove one of the mental barriers to getting things done - what if I try something and it doesn't work - how much time will I waste trying to revert?
GitHub - like Trac, without the pain
Trac is a neat web frontend to SVN that allows you to browse your source history visually, and keep notes about your project in a wiki. It's also a real PITA to install in my experience...
GitHub is a software as service tool that's quite similar to Trac. They host (and backup(ii)) your Git repositories for you, so there's minimal setup required. It's beautifully designed and very easy to use. It's also pretty inexpensive ($7 month for the cheapest version with private repositories), or free for open source projects.
Surely Git must be hard to install?
I installed git with MacPorts:
# sudo port selfupdate # sudo port install git-core +svn
On Linux, I was able to build from source without any headaches, so if you aren't on Mac OS, you should still find Git trivial to install.
Git is certainly a little confusing when you arrive as I did with your head full of how things are supposed to work in another source control system. I found these pages particularly helpful in getting to grips with Git, I hope you will too:
- Within a repository, SVN will store only parts that change for a branch, so your respository won't end up taking up lots of space if you have lots of branches. However, if you checkout a whole repository, you will get 1 file for every file in the repository.
- Though of course, every local checkout is a full copy of the whole repository. This is worth noting because you won't lose anything if GitHub go out of business, and I wonder how many people actually backup their SVN repositories if they host with a third party provider?
Posted by Ben @ 11:37 AM