Yet another Git tutorial. I've found that it's impossible to master Git by treating it like a black box- one _must_ understand how it works to truly understand it.
It's pretty sad that this one not only assumes that knowledge of the internals is unnecessary, it in fact praises such ignorance ("newbies can ignore its inner workings and view Git as a gizmo that can amaze friends and infuriate enemies with its wondrous abilities"). This is particularly true considering that the relevant parts of the Git internals are actually quite simple.
Your life is too short to learn and understand the internals of everything. The less I have to know about the internals, the more leverage a library or framework provides me.
Secondly, what is 'quite simple' to you may be incomprehensible to someone else. However, I still have to collaborate with these people on a project. If git is ruled out, because only the top 1% of people in software engineering can gain a sufficient understanding of the internals to use it, then it is utterly worthless to me.
I understand Git's internals well enough, but I don't, nor have I tried to understand the actual packing heuristics, nor do I believe that I need to, to be good at git. (Recent HN posting on the packing heuristics: http://news.ycombinator.com/item?id=1058204)
I don't understand packing heuristics either, and no, you don't need to understand it to be good at Git. What you do need to understand: what commit objects really are, and how they're connected to each other. This should cover branches, tags, rewriting history. There's no point describing porcelain commands in great detail: that's what manpages are for.
About starting somewhere, I agree. There are plenty of "cookbook tutorials" to take you through some everyday scenarios. In my opinion, it's much easier to screw up with Git than with SVN: so when this does happen, it's time to move onto understanding the internals.
sorry, but I disagree that it's easier to mess up in git. case in point, the rm command. in git the rm command will not destroy the existence of any actual data, in subversion it will. so an "accidental" rm in git looses you nothing but time in reverting correctly, in subversion you loose data, which is irrecoverable. similar things can be said for almost any git command. and those that could loose data require a force flag, almost every time.
this has been my most useful git tutorial, or more importantly, reference. it's great to come back to for how to deal with a situation that doesn't come up often enough, but when it does you need a concise answer on how to handle it.
