The History of The Royal Breakfast (Meet Git #6)

What are commits and how to read Git history?

Photo by Joanna Kosinska on Unsplash

Introduction

In the previous article¹, we were finishing our first recipe in the cookbook. Today, you will learn basics about what are commits, how they relate to each other, and how to view the history of the repository.

Let’s get started!

Commits explained

What are commits?

Well, we’ve already created a few commits in the cookbook repository, but what they really are?

Every time you tell Git to save your changes by entering git commit, Git creates, as you can probably guess, a commit.

A commit is a snapshot of all staged via git add command changes that have happened since the previous commit. Every commit contains information such as:

• New changes to the previous snapshot
• Author
• Creation date
• Message
• SHA-1 checksum, for example cab78b27856…, where usually only the first few characters matter, as long as you can uniquely identify the commit

Where are commits stored?

Where are these objects stored? As a reminder: within the .git subdirectory, so in our case cookbook/.git.

Luckily, we don’t need to know details about Git internals. What you need to remember is that your repository is the .git directory. This means, even if you accidentally modify the recipe for Royal Breakfast, or you even delete the file named royal_breakfast.txt, restoring the recipe is for Git a breeze, as long as you have the .git directory in place.

How do commits relate to each other?

Regarding commits, every commit is linked to its parent commit. At this point, I would like to mention there are two special cases, that may occur:

• A first commit in the repository doesn’t have its parent commit
• Merge commits can have more than one parent commit (we haven’t talked about merging yet, but I’ll show you this scenario in one of the next episodes)

To better understand the association between commits, let me give you an example based on the cookbook repository.

The newest commit, cab78b2, is linked to c033558, which means that the parent of cab78b2 is c033558. Then, commit c033558, is linked to the initial commit in the repository, that is 1033ca3. Eventually, commit 1033ca3 has no parents.

Every commit is linked to its parent

Don’t lose your HEAD

Note one more thing: do you see that blue HEAD marker on the screenshot above? This is a so-called pointer, and it’s placed usually on top of the branch, if your workflow is straightforward (like in our case).

There are basically two main responsibilities of the HEAD pointer:

• It shows what state of the repository your working directory represents
• It points where the next commit will be added to

On the screenshot above, HEAD is pointing to the commit cab78b2. Location of HEAD simply tells you that files in the cookbook directory look just like when this commit was performed (unless you modified the text file with the Royal Breakfast recipe).

Also, if you are about to perform another commit, it will appear on top of cab78b2, because this is where HEAD points to.

Manipulating the HEADpointer is really useful, for example, if you want to bring your project to the previous known state. Traveling in time and reverting changes in Git is mainly associated with moving the HEAD pointer, and this topic will be covered in the next episode.

About branching

In terms of branching, I haven’t covered this topic yet, but for now you only have to know that each repository have at least one branch, and in our repository this branch is called master, or main, depending on your Git configuration. We always work in the context of a particular branch, so we can say that we’ve been working on our recipe on the master branch.

What does it mean? Commits organized like this allow you to do interesting things, for instance:

• comparing what changes have been introduced and when
• traveling in time/reverting changes if you change your mind

View the history

In previous episodes, we created three modifications (commits) in our repository, but how to check what’s been introduced and when?

It’s easy to remember all these things when the project is super simple like now, but when the project grows, it’s getting more and more difficult to remember everything. To view and analyze the history, Git comes along with several tools that I’ll describe below.

Using git log

Using git log is the easiest way to find out what’s going on with the repository. The git log command shows the history of the branch you’re currently working on (master, as there is only one branch in the entire repository). Each entry represents a single commit, and it consists of a set of vital information about the particular snapshot.

What’s important, the entries are ordered from the newest to the oldest, so if you want to check the history in chronological order, read the entries from the bottom up. This may seem odd at first, but we’re usually interested in recent changes, so that’s why they are listed first.

If the history contains so many commits that they don’t fit on a single page, use B (backward), F (forward) and Q (quit) keys on your keyboard to navigate.

Recent changes are listed on top

Colon at the end means there are more pages to show

Viewing history as a graph

The simple git log is okay, but if you want to use Git really like a Pro, I have something better for you.

Now, let’s suppose that our cookbook will contain a few more recipes than it currently has. Moreover, if you want to develop recipes independently of other recipes, you will probably appreciate working on separate branches, and the history of the repository may look like the screenshot below.

The history of the repository represented as a graph

Every light green label, i.e. master, spaghetti_carbonara, tiramisu_omg, represents a separate branch. As you can see, the history is not linear anymore, so these recipes can be developed independently.

In this scenario, the simple git log doesn’t work anymore. I mean, it does work, and it still produces output, but the output of git log is limited to commits from the branch you are currently on (HEAD is pointing at master branch).

git log shows commits only from the current branch (master)

It’s much nicer to have a bigger picture of what the repository look like, for example what other branches exist in the repository, and how they merge, if at all.

To achieve this, I encourage you to start using git log --graph --all --oneline --decorate.

Here’s a short explanation of what particular flags do:

• --graph makes every commit is an asterisk connected with a line
• --all displays all branches within the repository
• --oneline condenses information about a single commit into one line
• --decorate gives some extra formatting (depending on Git version, decorating can be enabled by default)

Aliases in Git

That command is nice, but do we really have to re-type it over and over again, every time we want to use it?

I admit, the command displaying the history as a graph it’s a bit lengthy, and if I had to type it from scratch, this would drive me nuts.

Fortunately, Git has a cool feature called aliases. If you have a command that you often use, you can create an alias for such a command. This allows you, for example, to make the long commands much shorter.

What if I told you that instead of writing git log --graph --all --oneline --decorate you could just use git lga?

To make git lga available in Git, paste in the terminal git config --global alias.lga log --graph --all --oneline --decorate. This will add the new alias in the global scope, which means from now on, git lga will be available for your system account.

What’s next?

Since we haven’t exhausted the topic of checking the history yet, in the next episode we will find out how to check what exactly was committed and when.

References

[1] Krystian Szpiczakowski, Make the Royal Breakfast truly royal (Meet Git #5) https://medium.com/codex/make-the-royal-breakfast-truly-royal-meet-git-5-b7ba8a36f91