That is actually one of the better intros I have seen, which surprised me some-what (there are quite a lot of introductions to git now!). Possibly I've just used git enough by now -- albeit not intensively -- that it was easy to follow, but I completely agree with his contention that you have to understand the repository format to understand git, and he does a good job of of covering that in context.

Scott Chacon's gitcasts included a keynote he gave which also has a good explanation of the repository and how it works: http://www.gitcasts.com/posts/railsconf-git-talk. He has a peepcode book covering the same material, which I bought out of appreciation for gitcasts at the time.

Good tutorial. I think this is a more meaningful approach than e.g. trying to explain git in terms of SVN, because that reminds the reader of too much conceptual baggage, only to note later that it's largely irrelevant now.

It's actually a relatively simple model, when you focus primarily on the data structures.

If you're interested in the Git internals, I'd highly suggest reading John Wiegley's "Git from the bottom up":

http://www.scribd.com/doc/6377254/Git-from-the-bottom-up-by-...

I really appreciated your write up as a primer on git. Thanks for writing it. One issue I have with it, though, is that the part focusing on Pushing and Fast Forward Merges is either vague or incorrect and led me down some confusing paths. I'm specifically referring to the part where you claim "one common problem is when you do development on a branch and the branch changes on the remote repository as well... if you pull master from the remote repository, you will get a warning, and if you force the pull to go through, you will lose commit "

First off, a fetch will never result in a fast forward, since it is just modifying remote references, not merging local references. If you fetch in this scenario, it will not cause an error or you to lose your commit. It just updates the remote reference. You can then merge, resolve any conflicts and you're set. Doing a pull is just doing these two steps as one -- i.e. a pull = fetch + merge. After merging, you can push back.

This is a good guide for someone getting started with git, but does not really explain why you might want to use git instead of some other version control system, such as svn. The title of this work implies it's something more than an introductory tutorial, but that's really all it is.

undefined

Small correction, `git add -a` adds untracked files, too. `git add -u` does not.