First of all, I'm sure the author knows more about git than I do, so I don't wanna come across as trying to lecture an expert. But I do feel that his main point

First of all, I'm sure the author knows more about git than I do, so I don't wanna come across as trying to lecture an expert. But I do feel that his main point misses the mark. It seems to be centered around the idea that a lot of reasonable people are surprised by things git won't let them do (or, more accurately, strongly advices against doing). The problem is that most of these things are only "reasonable" from the point of view of someone who hasn't thoroughly thought through what a DVCS has to do. A lot of the "reasonable" questions are raised from the point of view of "this is a tool for sharing changes to code". But that is just a nice side-effect of what a DVCS aims to do – it is not the goal. I too have had to clean up git mistakes of collaborators for years, almost all of them rooted in a misunderstanding of what git does, or carelessness (amplified by git's arguably less-than-stellar naming conventions). But is there really any chance that any DVCS will be "easy" (or "not too hard") for someone who hasn't thought about and internalized what the goal of a DVCS is? It seems a bit like a person who only ever spreads butter complaining that knives are needlessly sharp. PS: My greatest success rate at converting people from "just hammer git commands until my code is on GitHub" to actually understanding what problem git tries to solve, and how to interact with it, has been from Mary Cook's wonderful Git from the inside out (https://codewords.recurse.com/issues/two/git-from-the-inside-out https://codewords.recurse.com/issues/two/git-from-the-inside...)