I appreciate the comment. To be fair, this was intended to be an introductory tutorial--it was written to teach Git to a friend of mine. Its purpose was to introduce Git in terms of underlying concepts rather than as recipes of commands, as most tutorials only provide. I'm not particularly of the view that "understanding" is the province of experts; novices are perfectly capable of grokking a system, given proper instruction.

I struggled with svn when I first started out with version control for this reason. I often found things explained as "this is how you do it" or "What if you want this? Type this!" which doesn't tell me anything unless I'm asking the correct question. I found that understanding branching was extremely important to understanding how the system works as a whole, but perhaps that's just when everything clicked.

I think many developer tools - and perhaps Unix-style tools in particular - suffer from this problem of skipping past concepts to syntax. There's an inherent expectation that you aren't a user who wants just the "shallow" common-case uses, but instead are going to go through a rite of passage where you learn the ins and outs of all the concepts the tool uses, make it part of your daily life, and piece it together with the other small powerful tools into some conglomeration that solves your problem.

This is great for developers, but bad for end-users, as a lot of users will run away before learning new concepts(they're busy enough already), while others will take a macho posturing attitude towards it and look down on the people who ran away. The community gets polarized. Git exemplifies this kind of thing, for better or for worse.

It's not a huge surprise that so many developers have switched from Linux to OSX, since the latter has made many more provisions towards the newbie end-user; it indicates that most developers don't want to take on this kind of burden, at least not all the time.