Whether you code individually or with a team, identifying individual commits is an essential task. For example, to create a branch, you must choose a commit from which to diverge; to compare code variations, you must specify two commits; and to edit commit history, you must provide a collection of commits. In Git, you can refer to every commit via an explicit or an implied reference.
You’ve already seen explicit references and a few implied
references. The unique, 40-hex-digit SHA1 commit ID is an explicit
HEAD, which always points to the
most recent commit, is an implied reference. At times, though, neither
reference is convenient. Fortunately, Git provides many different
mechanisms for naming a commit, each with advantages, and some more
useful than others, depending on the context.
For example, when discussing a particular commit with a colleague working on the same data but in a distributed environment, it’s best to use a commit name guaranteed to be the same in both repositories. On the other hand, if you’re working within your own repository and need to refer to the state a few commits back on a branch, a simple relative name works perfectly.
The most rigorous name for a commit is its hash identifier. The hash ID is an absolute name, meaning it can only refer to exactly one commit. It doesn’t matter where the commit is among the entire repository’s history; the hash ID always identifies the same commit.
Each commit ID is ...