From the course: Version Control for Everyone

Going back in time - GitHub Tutorial

From the course: Version Control for Everyone

Start my 1-month free trial

Going back in time

- [Instructor] In this video, we're going to start exploring some of the ways that you can go back through your project's history. You might do this so you can share a previous version of a file or folder, or just for curiosity's sake. I have enough work in this project now that I can go back and be able to notice some of the things that have changed. So let's start by going back to the point where we added this question about the MEAN apps. What I want to do is check this out so we want to check out the project right at this point. I'll check out that commit. Now there's a few things that we'll notice at this point. Looking here, it was the faq.md file that was modified. And up here, I suddenly have some new changes. Those .ds store files, that I told Git to ignore, are back because Git is no longer ignoring them because I added that file later in the history. If I open this file here in my editor, I can see that various other changes that I made later are no longer here. I have this h1 tag, not the markdown version of it, if I switch the file for a license, nothing is here. Switching back to Sublime, again remember that the questions about licensing, the change to the header, all these other things happen later. Git has actually modified the file as I can see it on disk, so it's the previous version, exactly as it was before. And that's not just the case for single files, it's the case for the entire repository. So if I open up my file browser, there is no file about migrations here. If I switch over to the finder, and look for it here, it's not there either. Git tracks everything. So if the files are added or removed, and I switch back to that prior state, those files will not be there. But if I go back to the master branch and check that out, everything is restored to how it was before, this file exists again, all those little dot files are ignored as they should be. Now what if I wanted to see what has changed within a single file over the entire course of the project? To do that in Sublime, I can open up the side bar, switch to the contents area, and change to the TREE view, which shows me everything in the project. If I click a file of interest, in this case the FAQ file, I can see annotations here of who made these various changes and a little commit hash as Git calls it, this big alpha numeric string here. That's a unique identifier within this project for that change set as it's called. But if I want to see the whole thing, here in the navigate menu, I have file history. This lets me browse through everything that's in this project and pick a file to see only the commits that affected that file. And then I can go through and look at the diffs to see what changed in each one. Different apps will have different ways of showing you this file history or the log as it's called. The Git command that goes with it is Git log. Over here in Fork for example, I can switch to the all commits view and then looking in here, I have the file tree. I can choose a file and show its file history as well. A similar idea, but presented a little differently. Depending on what app you're using, it may be called the file history, it may be called the log, it may be called something else, but almost every app will offer a feature like this. I can hit the escape key to dismiss that little search box at the top and I can remove that side bar up here. If I want to search for something within my history, I can use Command or Control F here in Sublime Merge and it starts out with this file search that I was just using, but if I clear all that out, I can search for almost anything. It gives me this query syntax that tells me all the different kinds of things that I might want to look for. So let's say I want to look for license. Then Sublime has searched the commit messages and shows me a commit message that includes that key phrase. This is another thing that will be different in the different apps that you use. Sublime can search pretty much everything. Most version control apps support searching your messages or your commit hashes, which are these, so explore the options that are available to you in the app that you like. If you're using the command line for Git, this is called Git Grep, G-R-E-P. One more thing about the history. If I want to mark a point in history that I will surely revisit, whether it's a version of the file that I knew I had to send to a supervisor or a colleague, or if it's a release of the entire repository, I can tag it. And to do that in Sublime, I can right click commit and then choose create tag at commit. And now I can create a unique tag for this commit. Let's say that this was a release on a particular date. Say this version was released on November 30th of 2019. I don't need to add a message to it and now I have this tag that I can refer back to to help jog my memory in another way about what this particular version of the repository was used for. So that's an overview of some of the ways that we can go back through the history of what we've done to extract some more information and get previous versions.

Contents