This 'reference' is, at best, full of inaccuracies and incorrect terminology, with diagrams that are overly complicated and ridiculous. For example: <a href="http://marklodato.github.com/visual-git-guide/merge.svg" rel="nofollow">http://marklodato.github.com/visual-git-guide/merge.svg</a>. What the fuck?<p>This guide will only make your understanding of Git worse.<p>It uses incorrect terminology to mislead what Git is actually doing in a number of situations, starting with the first sentence of the first section: <i>The four commands above copy files between the working directory, the stage (also called the index), and the history (in the form of commits).</i><p>Git doesn't care about files, but <i>changesets</i> so this should raise a red flag with anyone with even a passing knowledge of how Git works. This is either a fundamental flaw in the understanding of how Git works by the OP or intentionally misleading wording.<p>In the <i></i>Commit<i></i> section, the OP writes: <i>It then points the current branch to this new commit.</i> I don't like this wording because it makes it seem like a branch is something other than a reference to a particular commit (which is available in .git/refs/heads). Really, any reference to "current branch" should be replaced by HEAD, because the current branch is nothing other than HEAD, and HEAD of course is just a commit.<p>In the <i></i>Checkout<i></i> section, the OP writes: <i>The checkout command is used to copy files from the history (or stage) to the working directory, and to optionally switch branches.</i> This is blatantly false. `git checkout` doesn't "copy files"; it may move HEAD or it may get rid of any changes in the working directory, and in doing so may change the state of the files within the local repo.<p>In the <i></i>Committing with a Detached HEAD<i></i> section, the OP writes: <i>Once you check out something else, say master, the commit is (presumably) no longer referenced by anything else, and gets lost.</i> This is only partly true. The commit still remains in the reflog and can be retrieved up to the point that garbage collection is run. It's incorrect to tell someone their commits are lost as soon as they `git checkout` another treeish.<p>This guide should be binned in favor of EdgeCase's Git Immersion (<a href="http://gitimmersion.com/" rel="nofollow">http://gitimmersion.com/</a>) and Scott Chacon's Pro Git (<a href="http://www.git-scm.com/book" rel="nofollow">http://www.git-scm.com/book</a>).
Awesome! Very clear and well-written reference.<p>I wish someone would make a reference like this for remote branches and repos, I always keep forgetting commands for setting upstream branches, checking out remote branches and having them tracked, etc.