Version Control with Git

Identifying Commits

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 reference, while 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.

Absolute Commit Names

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 ...