The biggest problem with people's attempts to wrap their heads around Git, its awful UI notwithstanding, seems to be an insistence on thinking of it foremost in terms of the experience of running any given command. I.e., trying to understand it from the outside in. Indeed, it's awful UI certainly hurts the process.
Git's the stupid content tracker. Take a work consisting of a bunch of files, snapshot them, then create a new work (consisting of a lot of similar files, to be sure, but where others differ in some way). Git concerns itself with both of these collections as collections. It's true that it's got all this "branching" imagery, but that's an attempt to describe the relationships between the collections from the metadata attached to each one (collection 0ffcd473 calls collection f7d0c770 its parent). The branches are synthetic, imaginary. Not a lot different from a family tree or the "branches" you would get if you started mapping out the provenance of religious texts copied from another but each with their own copying errors (or deliberately editorialized content). The branches aren't really there—they exist as an aide for the researcher. The only real difference is that Git actually has explicit metadata, but still, the branches aren't there.
Focusing on Git's on-disk representation or other internals misses the point. The main thing is getting the files in the collection you're putting together right now to look the way you intend right now. Everything else is recordkeeping. (At least it should be—anything (whether it be a given tool, workflow, etc) that depends on it being any more complicated than this is fundamentally broken.) Git's whole deal was about being an alternative to manually futzing around with tarballs and/or multiple directories of source code sitting next to each other on your disk. (It's still that, but with a somewhat involved—but not very interesting—deduplication scheme in userspace. The other details are even less interesting than that.)