@graydon I'll agree with the latter point - a "how we use git here" guide is essential. I just remember trying to understand git in the late 2000s and how git terminology seemed to intentionally and unnecessarily differ from every other VCS. Docs were sparse and impenetrable and I wound up learning Mercurial instead because it was learnable. I hate that git is conflated with DVCS in general because it is such a niche tool that doesn't translate well outside its niche. We've had commit, branch, and merge forever - why a whole new vocabulary was needed is beyond me. But that's not surprising since I'm not a kernel developer.
@arclight Something that is free and sufficient tends to win, and git's selling point is that your source control problem is not as challenging as the problems it was created to solve.
The terminology mostly comes in because it isn't doing commit, branch, and merge, it's using a distinct abstraction, and the words for the abstraction weren't there so people just grabbed whatever didn't run away quickly enough. I agree that the result is horrid confusing. (git-scm docs make a heroic effort.)