Thanks for the reply!<p>I agree that some of the commands have a <i>very</i> large array of options. I see many these options as very specialized tools (and certainly don&#x27;t claim to know all (or -in some cases- most) of them). I, too find the &quot;git config&quot; command to be largely useless. Its value is in scripts or in Git frontends. Also, the git-config manpage has a complete listing of all valid git config options. So, there&#x27;s that. :)<p>&gt; Commit, checkout, and reset seem rather more complicated than necessary and don&#x27;t do anything useful in their default forms...<p>When called with no args, commit records changes staged with add&#x2F;rm&#x2F;mv in the local repo&#x27;s history. Checkout changes the tracked contents of the working copy to that of another point in the repo&#x27;s history (so it is meaningless to call it without an argument), and git reset is destructive (and has no --force option), so it makes sense to require an argument. [0]<p>In regards to commit and checkout:<p>I came to git by way of Subversion. These two confused me for quite a while. What helped me to understand the logic behind them was to realize that -unlike SVN- git has<p>* The working copy, which is manipulated with a bunch of commands<p>* The area where changes that will be included in the next commit live, which is cleared out after every successful commit, and is manipulated by add, rm, and others<p>* Your local repo, which is manipulated with commit and checkout<p>* One or more remote repos, which is manipulated with push, pull, and merge<p>But maybe you already had this solidly in mind, and this explanation was a waste of your time. :(<p>&gt; As always, trying to read the documentation leaves me with less understanding than I had before I started.<p>Have you familiarized yourself with a significant fraction of git&#x27;s vocabulary? The man pages became much clearer once I did so. [1]<p>&gt; ...for reasons I cannot comprehend they also get involved in merge resolution, where they perform tasks with no visible relationship to their names or their normal jobs.<p>Oh. That&#x27;s because a merge operation adds a series of commits from one or more branches into another branch and effectively makes a <i>new</i> commit with the result of the operation. If conflicts can be automatically resolved, then they are. If they cannot, then it&#x27;s up to you to stage the changes you want to see in the merge commit (using add and friends) <i>just</i> like you would do when preparing any other commit. Does that make sense?<p>&gt; I have no idea what reflog would do; is there a flog command too?<p>Nah. It&#x27;s a command for examining and manipulating the <i>ref</i>log, which is -effectively- where git makes a record of every change that happened to your repo. You pretty much never need to use the command, but I have used to see just how git handled a set of complicated squash and commit reorder operations. From the man page:<p><pre><code>  Reference logs, or &quot;reflogs&quot;, record when the tips of branches and
  other references were updated in the local repository. Reflogs are
  useful in various Git commands, to specify the old value of a
  reference. For example, HEAD@{2} means &quot;where HEAD used to be two moves
  ago&quot;, master@{one.week.ago} means &quot;where master used to point to one
  week ago in this local repository&quot;, and so on. See gitrevisions(7) for
  more details.
</code></pre>
If you&#x27;ve gone on a mad history rewriting spree and have confused yourself (or simply accidentally moved a branch a while back and can&#x27;t remember where it used to point), you can use reflog to trawl through the change history to save yourself.<p>&gt; I am generally more inclined to use stash or a second working directory than to deal with branches, since it&#x27;s less busy-work.<p>I&#x27;m curious. What busy-work do you have to do? I typically just have to do: &quot;git branch whatever; git checkout another-branch; git branch -D some-other-branch&quot;.<p>[0] Though -conceptually- a substantial portion of reset&#x27;s functionality overlaps with checkout&#x27;s functionality. So, that&#x27;s silly and nonsensical.<p>[1] Not that I&#x27;m implying that such a thing is be <i>required</i> to use git, mind.