Git has an easy way to mark a commit hash, even two. One is to create a branch. Another is to create a tag. Both are extremely cheap.
A branch is nothing more than a pointer (or mark) to a commit.
This realisation along with the `git reflog` command I wrote above, made for a tremendous mental shift and suddenly almost everything around git just clicked together.
A tag is.
A branch has the additional feature that it's a moving target with new commits, which is maybe not what you want in OP's case.
Yep; the way I like to phrase it is "symlink". As in, .git/refs/heads literally contained symlinks in it pointing to commits. (It doesn't anymore because Windows.)
But what you usually get instead is "this is a command to commit, this is a command to push, and this one to pull, here's how you make a branch, have fun" - and then people complain that git is complicated because they end up with situations they don't understand. Well, duh - any new concept seems complicated until you take a closer look at it, and if you learn git this way you never actually did try to understand it. It's a data structure manipulation tool, so it's in your best interest to have at least some rough understanding of what data structure it operates on. Otherwise it's like trying to use a word processor without knowing how to write.
As another example, I find it completely backwards to teach `git pull` before `git fetch <remote> <ref>:<local_ref>`. How is one supposed to understand what `pull` does this way? However you imagine it at this stage, it's going to be wrong and will make you end up confused later on. Once you know how fetch works and what merge is, `git pull` becomes obvious. It doesn't work the other way around.