In this chapter, we are going to learn how to navigate the repositories commit tree.
In order to do that, we need to start off by talking about the ways that we can
reference commits in Git.
We have covered a few basic ways already, but there are others that are going to
be really useful to know.
We will start off by introducing a new concept in Git called tree-ish.
It's kind of a funny word, we've already talked about what a tree is in Git.
It's the structure of files in the Git repository.
It's similar to a directory in your file system.
In Git, tree-ish means something that references part of the tree.
It's ish because what that something is can vary widely.
The suffix ish indicates that it's like something but maybe in a vague way.
Tree-ish is an important term to know, because it does show up in the Git documentation.
You will be looking up how to use a command, and it will tell you that you can
pass in a tree-ish as an argument to that command.
Now in its simplest terms, a tree-ish is a reference to a commit because that
commit then in turn references the tree, the Git repository and all the files
that are in there at that point.
So if you have a hard time thinking about all the things that a tree-ish can be,
the simplest version is that it's just something that points out a commit.
So how can you reference a commit?
The easiest way to do it is to use the SHA-1 hash, to use the entire 40
character string in order to reference the commit.
Git will always know which commit we mean because each one of those 40
character strings is unique, and as a side note, if you were wondering, how Git
make sure that all those are unique, it doesn't, but the odds of it not being
unique are astronomical.
We are talking you would need billions and billions of objects in order to have
a chance of having two objects that have the same SHA-1 hash.
It so highly unlikely that, for practical day-to-day purposes we assume
that they are unique.
The other way we have seen that we can refer to a commit is using a shortened
version of that hash.
We don't have to have the whole thing, we can just use a portion of it, and
because those numbers are so unique, Git can use that small portion and still
find the object that we were looking for.
We do have to provide at least four characters, and we have to provide enough,
that it is unambiguous.
Now being unambiguous depends on the size of our project.
If we have a project that only has five commits, well then 4 characters is
enough for it to know which one of those 5 commits that we're talking about.
If we are working on a mid-size project, you typically want to have something
like 8-10 characters, and if you are working on a really large project, one that
had millions of objects committed into it, something like the Linux Kernel, well
at that point you want to have 12, 13, maybe even 15 characters to make sure
that Git can find the object that you are looking for.
My advice is to stick to about 8- 10 characters unless you need more.
And we have also seen that we can reference a commit by using the HEAD pointer.
The HEAD pointer remember always points to the commit that's at the tip of the
currently checked out branch.
So that's going to be a tree-ish that points to part of the tree.
We can also use a branch reference. If we use a branch reference, then we are
referring to the tip of the branch.
Now it doesn't have to be the currently checked out branch, it can be a branch
that's not checked out.
We will talk a lot more about working with branches in the next chapter.
We also can use a tag reference.
We are not going to cover tagging in this tutorial, other than just to mention
that it is another way that you can refer to commits.
And the last way that we can refer to commits is by using any one of these
methods and then referring to that object's ancestry.
Let me show you how we do that.
So if we want to refer to the parent commit of something, we first provide the
reference for what we want to focus on, and then we say, find its parent by
using the caret. So that caret character comes right after it, you can think
of it is pointing up, pointing up to the parent on the tree.
If you think of like a genealogy chart where the grandparents at the top and the
children come down, we are moving up.
So we are moving up to the parent, and that's what the up arrow nature of the
caret suggest to us.
We can also use a tilde notation, that is to have a reference to the commit
and then a tilde followed by the number of generations we want to go up.
So HEAD going back one, we can also leave off the one, and it's just assumed.
Most people tend to use the caret in this case instead of the tilde, but
they do the same thing.
If our HEAD commit is acf87504 then all five of these, all refer to the same thing.
They all refer to the parent commit of acf87504.
Now in addition to the parent commit, we can refer to the grandparent commit.
Of course, if we want the parent of the parent, well then we just provide two up arrows.
We say start at the HEAD and go up twice, that will give us the grandparent.
This is where the tilde notation becomes a lot more useful because now we can
say HEAD~2, and it's especially apparent when we have the great grandparent
commit because then we start having a whole lot of caret characters coming after
our commits, whereas the tilde notation is much more compact and clear as to
exactly what we were doing.
We are going from the HEAD, we are moving back three commits to the great grandparent.
So these are some useful ways that we can refer to commits that are in the commit tree.
In the next movie, let's put these into practice and actually try using them.