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.