I think the problem is that the guide doesn't explain the vocabulary it uses at all. There are programmers (and definitely non-programmers) who might not have heard the word "tree" used to describe a directory filled with files and other directories. It's immediately clear once it's explained, and the guide even has little drawings that look like a directory tree, but for people new to version control and people who have used CVS or SVN this use of the word might be foreign. The same with "commit" since someone coming from another system has a different idea of what that means and someone new to version control has no idea.
Honestly, I'm not even sure you need to talk about "trees". The first chapter of Pro Git doesn't mention them at all, and this section describes the working dir, the index and HEAD without using the word: http://progit.org/book/ch1-3.html Instead he talks about "snapshots" and "stages".
I found it pretty helpful with the use of the word "tree" (got it from http://progit.org/). But I definitely need to add some kind of glossary to the page.
Thanks for your feedback! I completely understand your point. Maybe it would make sense to make another guide with an intro on Source Control Management systems and link it in the git guide. Currently, you need to have a little bit of knowledge on an SCM. But I will think about it.
Hmm, I'm not sure "having a little knowledge on an SCM" does the trick. Let's assume that I've used subversion for years (which surely is SCM). Therefore, for instance, I know that a repository is something on a server that can hold all relevant for my current team (we'll checkout a subdir for each of subproject). Also, I know that committing means sending a change to the server. I also know that I can lock a file and then nobody else can commit it, handy!
The meaning of nearly all SCM-related terms in your tutorial are highly git-specific. Making an SCM intro does not really help that. You need to make a git intro.
I don't know if they are necessarily Git specific, but probably are distributed version control system specific. For example the concept that committing would record your changes to the local repository wouldn't make any sense to a Subversion user, but would make a lot of sense to say a user of Mercurial.
One technique I use is trying to explain the underlying concepts using analogies to what people already know. Most people are familiar with using "Save as..." to create MyResumeOct2010.doc, MyResumeFinal_v1.doc, MyResumeFinal_REALLY.doc, etc. Version control is like a beefed up, automatic "Save as...". You can jump to any version without a mess of different files.
Distributed version control lets you "peel off" individual changes and send them to anyone. If you are making a shopping list with 3 people, you can "peel off" the items that Alice, Bob and Charlie added and put them on your own list.
Once the concepts are clear, you can give them proper names (diffs, revisions, commits, etc.) and things start to click. Anyway, that's what I've found helpful, good luck!
I found this guide very useful, so thanks for making it. :) I've used SVN, Mercurial, and git before, so knowing those made this easy to digest. Plus it covers stuff about git I never knew existed, like gitk. So cool!
