As a guide to understanding Git, the article fails; he mentions many git terms, but doesn't explain any of them. As a guide to others' guides to understanding git, it only mentions one: Mark Lodato's "visual git guide" [1]. There are many, many other tools and guides for learning and enhancing git. One of the blog's commenters mentioned Legit [2], which the blog post's author may personally find useful.
Offering a constructive means to improve Git is the best non-obvious point an article like this can make, but the author doesn't make it: I came away from this article unsure what, if anything, he's advocating for improvement. Better documentation? A better set of commands? A better set of metaphors? A higher-level wrapper? Better GUI tools? More features in web UI's like Github [3] or Gitlab [4] [5]? A complete switch to some other current or future version control system?
To be fair, he does mention a couple of these concepts in passing. But the best way he could help improve the situation is by engaging with them head-on, giving developers something actionable -- working code would be best, but a sketch of a GUI, a spec for a new command-line interface, or an explanation of an improved metaphor for a particularly confusing git concept would also encourage productive discussion. (I don't think much of his advice to "Let people who never learned to program write the next great version control system" (paraphrased) as something that's advisable or even possible.)
[1] http://marklodato.github.com/visual-git-guide/index-en.html
fetch - fetching the objects and metadata from a branch or branches from a remote repository
pulling from upstream - fetching from a remote repository (upstream, in other words all the changes flow down the stream to you, colloquial expression), then merge in the objects you fetched
cherry pick - choose which changes to apply ("cherry pick" them, colloquial term)
filter branch - modify a branch's history via filters
untracked - files that aren't being tracked by the source control system
symlink - a symbolic link, not even a git concept.
rebase - replaying all the changes committed from one branch onto another. Literally taking one base, and changing the base of a branch. i.e. re-basing the branch
tag - marking (or "tagging") a significant change in the repository
HEAD, head (note, mentioned twice by author) - a reference to the head of the revision history
working copy - the copy of a branch that you work on
path - really?
stash - you start working on some code, then you realise you want to change to another branch. So you stash away the working copy for later.
clone - cloning an existing repository so you can have your own to work on. That's why it's a DVCS
submodule - an external project from the main repository
fast-forward - when you merge a branch from another branch, git has the ability to forward the revision pointer quickly to the right point, see [1]
merge - merging changes
origin/master - the original repository. Convention.
staging area - also known as the "index", basically the concept is that you checkout a branch into a directory (called the working copy, see above), then you commit any changes into a staging area, then you push the changes into the repository
See? none of this was particularly hard to understand (although I grant you that "rebasing" and "fast forward" is a tricky concept, but hey, it's a source control system)
[1] http://git-scm.com/book/en/Git-Branching-Basic-Branching-and...
