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.
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.
Thanks for pointing this out--this is either a new feature since I wrote the tutorial, or I didn't get it right the first time around. I think it is correct now.
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.
I appreciate the comment. To be fair, this was intended to be an introductory tutorial--it was written to teach Git to a friend of mine. Its purpose was to introduce Git in terms of underlying concepts rather than as recipes of commands, as most tutorials only provide. I'm not particularly of the view that "understanding" is the province of experts; novices are perfectly capable of grokking a system, given proper instruction.
I struggled with svn when I first started out with version control for this reason. I often found things explained as "this is how you do it" or "What if you want this? Type this!" which doesn't tell me anything unless I'm asking the correct question. I found that understanding branching was extremely important to understanding how the system works as a whole, but perhaps that's just when everything clicked.
I think many developer tools - and perhaps Unix-style tools in particular - suffer from this problem of skipping past concepts to syntax. There's an inherent expectation that you aren't a user who wants just the "shallow" common-case uses, but instead are going to go through a rite of passage where you learn the ins and outs of all the concepts the tool uses, make it part of your daily life, and piece it together with the other small powerful tools into some conglomeration that solves your problem.
This is great for developers, but bad for end-users, as a lot of users will run away before learning new concepts(they're busy enough already), while others will take a macho posturing attitude towards it and look down on the people who ran away. The community gets polarized. Git exemplifies this kind of thing, for better or for worse.
It's not a huge surprise that so many developers have switched from Linux to OSX, since the latter has made many more provisions towards the newbie end-user; it indicates that most developers don't want to take on this kind of burden, at least not all the time.
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.