Linux in a Nutshell, 6th Edition

Referring to Commits

Each commit in Git can be uniquely identified by its commitid, a SHA-1 hash code made up of 40 hexadecimal digits. Unlike revisions in centralized systems like Subversion, Git revision numbers cannot be sequential, since there’s no central server to assign the sequential IDs. Because it’s impossible for a human to remember strings of 40 digits, Git provides several more convenient ways to refer to commits.

Any Git command that can accept a revision can accept any of the following forms:

Full 40-digit hash

You can always simply supply the full 40-digit hash code, such as da87b5990c03a799ae7a581c2edb1287dba08a43.

Abbreviated hash

Since the 40 digits of a hash code are effectively random, it’s very unlikely (though not impossible) that there will be more than one commit with the same hash. Thus, you can refer to any commit by the first few digits of its name, as long as only one commit starts with those digits. People often choose seven digits as a reasonably safe length. For example, da87b59.

Tags

Using the git tag command, you can create user-friendly names for individual commits. For example, if you released version v1.1 of your software after making commit da87b59, you could run git tag v1.1 da87b59 so that in the future, you can always refer to a commit named v1.1. Tag names can be shared between repositories, but you have to do it explicitly using git push and git pull.

Local branches

Branches are similar to tags, in that they name a particular commit. However, branches ...