For those who aren’t familiar with git, I’ll start with a short summary. Git is the version control system that Linus Torvalds wrote when none of the existing alternatives were acceptable choices. Short enough?
Now, here’s why you should be using it: (Keep in mind that I realized this so recently that I’m still using Bazaar with a handful of Subversion repos still on the conversion TODO list)
- Git is VERY fast… subsecond-response fast. Torvalds wrote it that way so he could get response times of a few seconds when working on the Linux kernel, which has a big tree.
- Git is distributed. Every working copy doubles as a repository in full, so you can work offline just as easily as online and every time someone clones your source tree, they also make a backup of your repository.
- Git doesn’t just take care of your data, it protects it. Unlike many other revision control systems, Git will notice and inform you of corruption due to faulty hardware. Then you can just pull a good copy from a co-worker, your public repo, or a user who likes to live on the bleeding edge. Every commit uses SHA1 hashes to ensure the integrity of both the newest commit, and all prior commits. (which also foils anyone might try to edit an old revision of the code for nefarious purposes)
- Git makes it comfortable and easy to branch and merge as much as you want.
- Git’s command-line interface is actually comfortable. Commands like `git stash` and `git commit` are designed by programmers for programmers.
Aside from it’s speed, that last point is actually the most important for me (I’m horrendously lazy) and, ironically, the one that I didn’t discover until I actually tried it. As such, let me explain what that means in more detail:
First, `git commit`. In most version control systems, the “add” subcommand (`git add`, `svn add`, etc.) tells the tool to start monitoring the files for changes which will be automatically committed by the “commit” subcommand. In git, you have to run “git add” every time you want “git commit” to pick up some changes. Confused? Good, now I’ll explain why this is a good thing.
to get the usual behaviour you’d expect from something like Subversion, Bazaar, and the like, you can run “git commit -a” (-a being shorthand for –all. I’ve used the git config file to alias it to `git ci` for comfort) but what if you’ve been happily hacking away at two different pieces of your program (Let’s call them “bob” and “steve”) and want to commit them separately?
That’s where git’s different approach suddenly makes sense. Commiting them separately is simple and comfortable…
$ git add bob/
$ git commit
...type in your description for bob's changes...
$ git add steve_*.c
$ git commit
...type in your description to steve's changes...
As with so many things in Git, it’s an example of a non-obvious but simple change which makes your life immeasurably more comfortable.
Second, `git stash`. This one is a much simpler. What if you’ve been coding away at something and, before your changes are ready to apply, someone (eg. your boss) rushes in and tells you to fix HEAD (the newest commited version) immediately? Without “stash”, it’ll take you at least six commands to temporarily “stash” your changes so you can work on HEAD without losing them. With stash, it takes just three and they’re easy to remember: (As taken from the stash manual)
$ git stash
... make the emergency fix ...
$ git commit -a -m "Emergency fix for the FOO problem"
$ git stash apply
Of course, don’t let that stop you from using Zack Rusin’s Git Cheat Sheet. It’s always nice to have a quick reference card handy, after all.
UPDATE: As a Linux user, I almost forgot to mention that yes, the Windows port is quite usable. The big scary warnings are actually mainly messages that can be summed up as “Windows doesn’t have this feature that Linux git users might be used to”. There’s a slightly aged GMANE thread you can check if you want more details.