You don't need to understand git's internals; I for sure don't know how it does delta compression of pack files etc. to provide you with efficient storage of snapshots and whatever else it does.
However, what you do need to understand is the model that git uses, which is extremely simple.
Git provides you a way to store snapshots of data into an on-disk graph data structure* that you can sync to and from remote repositories. You also get refs to store symbolic references to the snapshots in the data structure, and you can sync those too.
That's pretty much my mental model of git in its entirety, and it allows me to merge, branch, rebase and perform all kinds of commit surgery with ease, because I can always tell what effect an operation is going to have on my data structure (and even if I'm wrong, I can't lose data)
I seriously can't see how it could get any simpler.
(*) a git repository can actually contain several separate graph data structures, but that's usually not what you want...
However, what you do need to understand is the model that git uses, which is extremely simple.
Git provides you a way to store snapshots of data into an on-disk graph data structure* that you can sync to and from remote repositories. You also get refs to store symbolic references to the snapshots in the data structure, and you can sync those too.
That's pretty much my mental model of git in its entirety, and it allows me to merge, branch, rebase and perform all kinds of commit surgery with ease, because I can always tell what effect an operation is going to have on my data structure (and even if I'm wrong, I can't lose data)
I seriously can't see how it could get any simpler.
(*) a git repository can actually contain several separate graph data structures, but that's usually not what you want...