IMO the best way to think about git is at a happy medium level of abstraction (which most people tend toward anyways, it seems), where a commit is a snapshot, b

IMO the best way to think about git is at a happy medium level of abstraction (which most people tend toward anyways, it seems), where a commit is a snapshot, but can be thought of as the diff from its parent to it; a repo is a tree of commits over time (where lines can merge, so it's technically a graph, rather than a tree); a branch is a series of commits represented by a pointer pointing to the last commit in the branch, and you can think of that series of commits as either going back all the way to the initial commit or just back to another branch from which it diverges, depending on what you're doing with it. Etc. And then the commands operate on those things to achieve the logical goal of the command. Re: Bad UI, I vacillate, but I don't disagree. I do think it needs to be said that people talk about git's internals not necessarily because the UI is bad, but also because git is so relatively clean and simple that you can talk about the internals. Conversations about other tools look simpler because most people can not reasonably talk about their internals in a casual format. So, in a weird way, conversations about git are complicated because, unlike with so much other software, people don't just throw up their hands and get along the best they can, talking only about the UI and the results of using the UI, living with a limited, abstract understanding. Git enables them to understand better, with some effort.