 Hello there. In this screencast, we're going to look at how to use github.com as a tool to navigate the history of a project that's managed with Git. So Git is a software version control system that's used primarily by software developers to manage the history of their code base. So it promotes collaboration and it gives people a way to navigate the history and see not just how the code is today but how it got to be that way. So what changes were made over time that made it what it is today. If you've never used Git before, that's alright. What we're going to start with is a high level overview of kind of the way that Git structures its projects and structures the history internally and that will give us a basis to navigate the history using github.com. So before we begin though, one minor caveat is that github.com is a great service but it's changing every day. So I'm sure that before I even release the screencast that there will be slight differences and those differences will just compound with time. So know that if you're watching this very long after we first put out that you may be looking at a much different interface but my hope is that the basic ideas will still apply because it is built on top of Git. If you want something much more full proof that's much more likely to be consistent far into the future, check out the other screencast that we're releasing along with this one that describes exactly how to use the Git CLI directly. So that is independent of github.com and that is tied, those instructions are tied directly to Git itself which are in some ways a lot more stable although as you'll find a little bit more bare bones you might say. So that said I think we can 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 the 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 note 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 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 read me file that explains what the project is. From there, we have a commit that implements some basic functionality in the software. I commit the 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. 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 going to be traversing for the rest of the screencast. Okay, so here I am on a project repository on github.com. And looking at this we can see there's a lot of information and a lot to do. Luckily today we're only going to be looking at the way that we look at the history and the way that we just kind of read things. So github.com gives us a lot of ways to do a lot of the things we would do with the CLI and they're not all just limited to reading. But we're going to limit ourselves just to that for now. So just to get an idea again the history of the project and how it got to be the way that it is. So we can see first of all that we're looking at the state of the project all the files in the project. So we can see this project has a readme.md, it has a license, it has some tests and some source code. And this is all well and good but the whole point of the screencast is to know not how the code is now but how it got to be that way. So while I can open up one of these files and see its contents that's not really as interesting to me for the screencast as it is to know how that file got to be the way it is. The first thing we can do is look at a log of all the commits or all those changes that happened to make that code that way. So when I click on the commits at the top left here I'm given a listing of each commit that happened in sequence. So going back to that graph we're looking at earlier we can see that since I'm on this master branch we can see 1, 2, 3, 4, 5, 6 commits we expect to see and those six commits are right here. The most recent is at the top and what we're looking at is just the commits subject but the message also has a body and so I can expand that and see that while some of these only have a subject like this one other ones have bodies and other ones have kind of substantial bodies and so those are hidden by default that I can expand them. I'm getting information about who made the commit and about when they made the commit and if for any one of these though you may be wondering well it's all well and good that I see this this information but are these commits supposed to describe changes to the software? We're not really seeing any any any code in these links but if I click on any one of them then what I'll find is actual listing of the changes. So let's look at this link for documenting a new feature. So we're seeing the information that we saw before just kind of rearranged and expanded a little bit. We still see the commit subject and the message body for the commit. We see the author and about when they authored it and if you've looked at this screencast for navigating with the CLI you'll recognize these shas as the unique identifiers for the commit. But just below that we're finally getting into the code or the actual changes to the files in this project. So we can see that for this particular commit we've changed the readme.md file. We've made up 10 additions in one deletion and here we're seeing the contents of that file and how they changed. So lines highlighted in red were deleted and lines highlighted in green were added. We can see that similarly for this file in the source directory there were changes although in this case there were only additions and no deletions. We can see that for this file we just added this js doc style comment describing the API versus in the readme what we added was a usage example. So for someone that was just getting acclimated to the project seeing how they might use it for their own work. So that's the way that we look at the log of all the commits on a given branch and then kind of drill down into a specific commit. But we can also see commits in a bunch of different ways. So we'll note for instance that next to each one of these files there's a link that looks like a commit message. And so this is actually that for the given file the most recent commit to modify that file. So if we wanted to look at the last commit to change the package.json file we would just click on this link here and now we're brought to the commit that made that change. But you can go through the github interface and find different links to commits all over the place and at first it might be a little bit intimidating to try to learn all those and whatever all of them. So for now it's probably best just to know that consistently you can always look at this listing of commits here to see all the commits that got us to where we are for this branch. But we've taken for granted so far the concept of a branch. We talked about earlier how a project can have many branches and that they basically are just references to specific commits. So if I wanted to look at a different branch for instance if I wanted to look at this from file branch well I can see that this drop down here lists all the branches in the project. So we see that the from file branch is listed here and practically speaking you'll see a lot of projects on github that have a lot of branches much much more than just three. So many more that github has this nice filtering mechanism and I can filter by some strings so here I'm only looking at branches that have the word file on them. So either way though I can click on from file and now github is telling me that my current branch is from file and you'll see that the latest commit in this case is this one that was implement the basic read from file feature. I'm now seeing that there's only two commits here and this makes sense because from here we'll see there's one commit and then two commits is the start of the project. This is reflected when I look at the log or the history we'll see there's the one commit and that's based directly on this. So knowing this it shouldn't be too big of a surprise that when we open up the read me we're seeing that there is no usage example. If I were to go back to the graph we'll see that from right here this commit is just based on this commit here and so that the change set or the commit that implemented that usage example was over here in this other branch. So that's why here when we look at the state of the file on this branch we're not seeing that information. So that's how we navigate around branches or that's one way. Of course there are more than one ways. A second way would be just to list all the branches by clicking on this tab here called branches and this is listing all the branches in the project but from there it'll be very similar. You can click on one of these and now we're suddenly looking at the basic functionality branch. So that's how you navigate around different branches but if to go back to the project's kind of default or base branch which is usually master but not always you can just click the link at the top of the page. That about does it for navigating a project on github.com. We've looked at just basically how to go through all the commits in the history and to navigate between branches and to look at not just the metadata about the commits but actually specifically how the commits modify the files that exist in the project. I hope this has been helpful to you to learn how to approach a project that's hosted on github.com and maybe it's gotten you curious about how you can use Git itself because you can use the Git CLI or command line interface to do to find all this information just as well. The nice thing about that is while it's not as flashing doesn't really have the same user interface it will work for projects that are hosted on other services like BitBucket or anything else really. So I hope this has helped give you the tools you need to start learning about projects and in developing a better understanding of their history and how they came to be. Thanks.