The primer says
"The git branch command lets you create a new branch of your project. It creates a new commit with a new pointer label pointing at it."
which is not correct. When a new branch is created it just creates a new pointer to the commit which one branches off from, there is no new commit made automatically.
That's a pretty good analogy, although you need to remember that a plain git branch is like a File -> Save As that doesn't keep the new name of subsequent File -> Save's
One need to be careful while using an analogy. Though at the outset it looks like it explains the branching behavior of 'git' it ain't so. Say I have opened a File and do a File->Save as on a directory mounted from an external storage (say mounted via NFS ). In such a case the file contents need to copied to that storage and there are two copies of the same content. But with 'git' branching that is not the case at all. When you create a branch you just create a new reference to a commit and you start from there, nothing more than that.
I've had to get quite a few people up to speed on Git. What I've found is that for most CS-oriented people, beating around the bush is really just getting in their way. If you create the correct mental model for them, much of git becomes self evident. This isn't easy and takes a couple of days of intermitent whiteboarding but everything 'clicks' soon enough.
Big things:
Explaining that the object name (d56abc..) is really a SHA1 hash of all the contents. Git then uses this name to uniquely identify Git Objects.
Git Objects consist of: blob (file), tree (directory), commit (pointer), tag (well.. its a tag..). When you do a "git checkout" you interact with commit objects. When you do a "git ls-tree master ." you are looking at a tree object.
Branching is done by putting the following in .git/refs/heads/branch_name:
d56abc..
And a branch will always just point to a commit object.
Finally, the working directory is of very little concern to git. It has handy functions to drop some of its stuff there for you and it can tell you some differences between its HEAD and your files, but really Git begins at the Index.
+ Lots of little things.
Edit: It is always fun to do a quick 'echo "dbc123.." >> .git/refs/heads/new_branch' and show someone that that is all it takes. It really quickly shows how not-scary git is. There is a ton of complex technology that enables its awesomeness but it is a relatively simple system.
The first section shows "git diff" as the command but shows output from "git status" below it with the only mention of "git status" in the entire post buried at the very bottom.
git status is very helpful in understanding the git because it shows you the differences between the working directory, index, and previous commi, index, and previous committ.
The first commit is missing it's 't', which it looks like the second one stole.
This is a pretty good guide, but it's marred by one major error:
"the index is your staging area where things go after using git add before they get committed."
That's not right. The index is where things go after MAKING EDITS IN THE WORKING DIRECTORY before they get committed. (What does "after using git" even mean?)
