I started naming branches 'post-its', as to me that's what they are, labels you place on the real 'branches' (the commit tree). You can take them of easily, move them, discard them, whatever you want. They are just volatile.

I should have said pointers. I didn't mean to overload existing git terminology. My point was just that they are pointers/references to some commit.

> They don't point to specific files or commits.

A branch points to the tip(last commit) of a particular timeline.

But they are also called symbolic refs in git terminology...

A symbolic ref is a ref that points to another ref instead of a ref that points to a commit. `HEAD` is a symbolic ref. (It should be your only symbolic ref.)

Unless it is detached. :)

That term makes sense.

But just as you wouldn't call a symlink to a zip archive a zip file itself, you also shouldn't call a branch a ref.

Hrm, but a ref is a file containing a hash, right? So if the hash is equivalent to the file, the surely a ref is equivalent to a symlink? A symbolic ref, in turn, should be a symlink to a symlink... Or something like that...

A ref points to an object. That object doesn't change unless the hashing algo was tricked.

A branch points to anything you want it to point to. It can be any ref you want and can be changed at will.

sha1 - object (e.g. 5a480efb...) file with sha1 - ref (e.g. master) file with ref - symbolic ref (e.g. HEAD)

right? Seeing as you can git update-ref branches, but you need to git symbolic-ref HEAD.

But it is a ref. It's an alias for the last commit of a particular timeline, as I said above.

So would you rather say a branch is a commit?

A branch is a pointer or symlink if you will.