 Hello. In the screencast, we're going to look at how to read the history of a Git project using the Git CLI, or command line interface. So Git is a version control system that's primarily used by software developers to manage the history of their projects. And because of this, one of the first things that people want to do usually when using Git is to get an idea of how the software got to be the way it is today. So that's what we're going to cover in the screencast is exactly, given a Git repo, what you can do to kind of look at its history and see how the changes kind of stacked on to each other over time. And if you've never used Git before, then that's all right. We'll start with a high-level overview of kind of how Git histories are structured. And then from there, we'll dive into a real repository, and we'll use the command line interface to explore its history. So let's get started. So at a high level, Git history is just a collection of commits. Now, commit is the word we use to describe a change to the code base, but it's more than just the change to the code. It's also information about who made the change, when they made it, and hopefully a short description that kind of gives context for the change. So in this graph, we can see that commits all have at least one parent. And they kind of point back to where they started. So in this way, commits kind of build on each other over time to get us to where we are today. So you can see that this commit would be the very first commit that a project might make. And then we might make a commit on top of that, one on top of that, one on top of that. And we can merge two commits, making a new commit. And that's sometimes referred to as a merge commit. And so this is just going to be, the state here is going to be kind of the combination of the state described by this commit and this one here. And any commit can have a name, and that's what we call a branch with git. So if we kind of just abstract or simplify this graph and just take away most of the words, we can see that when I refer to this as a graph, there's a lot of parallels to just general graph theory. Each one of these commits is sort of just like a node. And it can have parents just like in a general graph. And because of this, usually it's not really important to demonstrate that like merge commits are unique from regular commits. It's evident just from looking at this graph that this commit here has two parents. So it's a merge of two different commits. And now hopefully it's a little bit more obvious how branches really just are commits with names that we give them. But this is all still kind of abstract. So if instead we look at some sample commits with their titles, this might make a little bit more sense. So this would be the history of a git project that maybe a few people were working together on to implement different functionality. So you can see that all these commits are now boxes with their kind of title in closer than the box. And for the first box, we just have the commit that starts the project. And you can imagine that this just adds some basic structure and maybe a readme file that explains what the project is. From there, we have a commit that implements some basic functionality in the software. A commit that builds on top of that. So it says, given this new basic functionality, let's add documentation for that feature. And then a third commit that builds on top of that previous one that adds tests for that new functionality. And so all these commits are really just this one here is part of the basic functionality branch. And so you can see that from here, we can merge in this new functionality on top of the start project. And so now we have this merge commit is back in. And from there, we can obviously add as many more commits as we want. So here we're just adding one more that describes releasing a new version. So the state of the project currently, you would say, on the master branch is this new version. But as we saw with the previous graphs, we could have commits based on any other commit at any time. And so here we have a different branch called from file. And this is someone else maybe working on a different functionality altogether that's kind of unrelated to this. And so this is how developers are able to kind of work in a distributed fashion, because they can in this way kind of branch off as we say work on their own things that are maybe not directly related to each other and then later merge them back into a shared code base. And so that's basically what I get history looks like at a high level. And this is what we're gonna be traversing for the rest of the screencast. To get started with the CLI, we're gonna need a Git repo on our local machine. So I'm gonna use the Git command line to clone a repo or copy it from the net. So I've pasted in a Git URL. This is just a URL to a valid Git repository. And when I execute this, it's going to copy that commit from the web onto my machine. So now if I were to look around inside this, I can see that this is just a typical software project open source that has it's a node project. So it has all the things you would expect from a node project like a package JSON file. But I can open up the read me file and just see it a bunch of text describing the project and what it's like. So this is all well and good if all I wanted to do was use this project. But because I'm interested in how the project got to be where it is, I'm interested in the history. So it's not enough just to look at what the files look like right now, but we wanna use the Git CLI to dive into the history of this project. So the very first command we used to do this is Git log. So if I type Git log in the terminal and I can enter what I'll be displayed is a listing of all the commits that were used or that were made to get the project into the state that it's in right now. So remember the commit is just a change, a set of changes to the files and some information about those changes. So when we look at this in this log by default, all we're really seeing is that metadata about the changes. So you're seeing, we're not actually seeing code that's being changed, but we're seeing a listing of three commits. So this is one commit, for instance. And it has information about who made the commit, the time they made it, and then a description about the commit. The kind of alien looking thing here is this long spring of letters and numbers. So this is called a SHA. And what it is, is a way for the system to uniquely identify the commit. So this is important, we'll be using this in a little bit to reference specific commits and look at them in detail. But for now just know this is kind of a bunch of gibberish to us that we'll use to reference these commits specifically later on. So right now though, we're only looking at three commits and this is based on the example that we were looking at before. So we would expect to see more commits than just three, but still not too many. We can kind of page through, this is actually a list that we can page through and we can use the up and down keys to look at the commits that are farther back in the history. So we can step through and go all the way back and since we know there's only a few commits, we eventually get to the very beginning. We can use up to go back up and just look at how each change stacks on top of each other and basically what we're looking at is this list right here of these commits. So let's say that we're interested though in actually looking at the changes that these do. So right now we only really know a little bit of like metadata about what they are in a short description, but if we're interested in the actual changes to the code base, then what we'll need to do is use that SHA. So for instance, for this commit here, we're just documenting a new feature. We'll copy the first six or so characters from this identifier and to get out of the log we'll hit the Q key. Now we can use a new command called get show. And so we'll invoke get show with those characters and what this will do is show us the same information we're just looking at for that commit, but it will also append to this report the actual changes that were made to the code base when this commit was applied. So we're seeing the same information, the author, the date, the SHA and the description. But after that, we're seeing that the readme file was changed in this commit, that the lines in red were removed and the lines in green were added. And we continue to page down, we see that also a file, a source code file was changed. Here we're seeing that just a bunch of lines were added, just comments describing the API of this function. So a nice short commit that made the project just a little bit better because now other developers can kind of read about what's happening instead of having to parse the source code. And so that's the reason why when I open up, for instance, the readme file on a text editor, that's why these lines are here or that's how they came to be. So we can use show to look at any specific commit, but if we call show without any arguments at all, then we're given the commit that's most recent. And so it's most recent for this branch. But up until now, we've only really looked at a single branch. Even though in the graph we were looking at before, there are a few different branches. So if we wanted to switch out branches, the way we would do that, it's first find out what branches are available to us. So we can use get branch dash A, or we can use the long form, which is dash dash all. And this is listing out all the branches that are available. So if we wanted to look at one of these branches, specifically we would say check it out. So we would use get check out. And now I'm gonna type in origin, which is from right here. And we'll say origin slash, we'll do origin slash from file. So from file. So get is telling that we just checked out that branch correctly, and that it's also telling us a bunch of information about the state of the project. And this is only local, and it doesn't really matter for us today, because today we're only looking at kind of navigating the history. If we were to try to contribute to the project, then we'd have to understand this a little bit better. But for right now, it's fine just to know that we have that branch checked out. And so what we're looking at when we do get show now, is we're looking at the most recent commit. So we truly are kind of situated right here. We can also prove this to ourselves by opening up that readme file in a text editor. And we'll see that this readme file no longer has that change with the sample usage, because looking through the history graphically, we'd see that that was added over here. But if we're just situated right here, then that commit isn't part of our history. Of course, using git log, we can prove that to ourselves, because now we can see that there's just this one commit that is implementing this feature. And then directly above that or before that is the commit that starts the project. So that's basically how we would use the git CLI to navigate around a project and look at its history. We can check out master again. And we're back to where we were before. So when we type git log, we're looking now at the full project history. Of course, minus this one commit here. So that's basically how you would use the git CLI to get familiar with a project and its history. And there are of course many, many more commands and many, many more options for those commands. But for all the commands we looked at today, which again are log, show, checkout and branch, you can always type dash dash help at the end and get a manual page describing all the different options and how it's intended to be used. So if you wanna continue to learn or to tweak the behavior of any of these commands, then feel free to read up here. This makes for some really compelling bedtime reading. So enjoy that as well. I hope this was helpful and I hope that this gives you a good starting point to start investigating the history of git projects in the wild. Thanks.