Looking back at our Repository

Repository Logs

Alright! So we now know a lot about Git and its commands. Git not only offers you a way to maintain your files, it also offers you tools to check out older versions of the files when the need arises. Before you begin, make sure all our files are available in your directory.

The first command we will be using is the git log which as you might expect, shows you a log of all your commits in your repository. The log command displays the most recent commits first. Scrolling down will show you the first commit that we added about out README file. Let's break down the output of this log.

Checking Repository Logs

It starts with a unique identifier for each commit. Recall that we discussed that that Git uses a SHA-1 hash for security. This is used as a unique identifier. You may think it is easier to name the commits numerically. While that is true, some repositories are public and have a large number of people contributing, so it gets difficult to number those commits as they occur.

Below the identifier is the Author name that initiated the commit. This makes it possible to keep track of who is contributing to your project. A little down below is that date time information regarding the commit.

And finally, we see the commit message itself. Notice that each message provides adequate information on what was done in that commit. Now consider a situation wherein you added a feature to your project but was dismissed by the client. With this log, you can check exactly when this feature was added and the commit identifier associated with it.

Checkout a commit

So now that you know when this feature was added. But how do you check out the code for that feature. Don't worry, we don't need an actual time machine to get that code. Git provides us with the functionality of actually going back in time and checking out that piece of code.

Git uses the 'git checkout' command to recover an earlier version. For this, it requires the commit identifier. We don't actually have to type in the long hash value because let's face it, we are lazy. We just need the first 5-6 characters of the commit ID and we're good to go (most of the times).

Uh-oh. A scary message. Something about being in a detached head state. Well Git is just telling you that you have checked out an earlier version of the file! Also making changes in here would probably be dangerous. Let's checkout our first commit. Go ahead and type ls. If you've followed the steps of the tutorial, you will probably see only the README file. Hmm. That's weird. There is no trace of the file, file2, file3.

Checking out a commit

Before we freak out over it, let's understand that we are checking out an older version of the repository. When we initiated commit for the first time, we did not have file, file2, file3 at all! This explains the absence of those files.

Checking difference in commits

So let's get back to the present. We can use the 'git checkout' again, but where do we get back to? If you remember the 'git status' command, it showed a message 'on branch master'.

Running the following command will bring you back to the current repository state:
$ git checkout master

Type in ls again to make sure all your files are available. We have another method to check out older versions. The git diff comes in handy. It shows the differences between the two states. Just run the command with the identifier of the first commit and the last commit. Skip the first few lines in the output. Check the + sign which means content was added. It then proceeds to show the actual changes.

Checking difference in commits

There are graphical interfaces which are much clearer and easier to use, but this is the basic of it. That was all about the Git basics. Let's dive in deeper, shall we?