Exploring History

Last updated on 2025-08-26 | Edit this page

Overview

Questions

  • How can I look through older commits?
  • How do I review my changes?
  • How can I discard staged and unstaged changes?

Objectives

  • Explain what the HEAD of a repository is.
  • Know where to find a commit’s SHA.
  • In GitLab, look at changes made by prior commits.
  • Restore a file to the version before staged or unstaged changes.

As we saw in a previous episode, we can refer to commits by their identifiers. You can refer to the most recent commit of the working directory by using the identifier HEAD.

We have been adding one line at a time to mars.txt, so it is easy to track our progress by looking, so let us do that using our HEADs. Before we start, let us make a change to mars.txt, adding yet another line.

BASH 

$ nano mars.txt
$ cat mars.txt

OUTPUT 

Cold, dry, and everything is red, vampires' favorite color
The two moons may be a problem for werewolves
Mummies will appreciate the lack of humidity
Why are we talking about mummies?

Now, let us see what we get.

BASH 

$ git diff HEAD mars.txt

OUTPUT 

diff --git a/mars.txt b/mars.txt
index b36abfd..0848c8d 100644
--- a/mars.txt
+++ b/mars.txt
@@ -1,3 +1,4 @@
 Cold, dry, and everything is red, vampires' favorite color
 The two moons may be a problem for werewolves
 Mummies will appreciate the lack of humidity
+Why are we talking about mummies?

which is the same as what you would get if you leave out HEAD (try it).

Now let us switch to exploring the history of our commits using GitLab. On our repository’s main page, within the box showing your most recent commit, click “History”:

A screenshot showing a red box circling the button 'History' on the main page of the repository
Screenshot showing where to click ‘History’ in the GitLab repository main page

You will see a list of each commit you have made so far. The date, commit message, and an alphanumeric string are shown for each one. The strings are unique IDs for the changes, and “unique” really does mean unique: every change to any set of files on any computer has a unique 40-character identifier, called an SHA (Secure Hash Algorithm).

If we want to see the changes made in prior commits, we click on the commit message, which will take us to a page showing what was changed between this commit and a prior version:

A screenshot showing what was added to mars.txt in a single commit
Screenshot showing GitLab’s commit diff interface

Explore History and Prior Commits

Take some time to explore the GitLab interface.

What are a few scenarios where these features would be useful? How might the ease of exploring your history result in code that is cleaner and easier to read?

All right! So we can save changes to files and see what we have changed. Now, how can we restore older versions of things? Let us suppose we change our mind about the last update to mars.txt (questioning the topic of mummies).

git status now tells us that the file has been changed, but those changes have not been staged:

BASH 

$ git status

OUTPUT 

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)

    modified:   mars.txt

no changes added to commit (use "git add" and/or "git commit -a")

We can put things back the way they were by using git restore:

BASH 

$ git restore mars.txt
$ cat mars.txt

OUTPUT 

Cold, dry, and everything is red, vampires' favorite color
The two moons may be a problem for werewolves
Mummies will appreciate the lack of humidity

This command can be handy when you have been experimenting with some changes, but ultimately decide to discard them before you have staged any of these changes.

Git also has ways of reverting back to earlier versions of a file that you have already committed, but those topics are more advanced and we will not be covering them here.

Getting Rid of Staged Changes

git restore can be used to restore a previous commit when unstaged changes have been made, but will it also work for changes that have been staged but not committed? Make a change to mars.txt, add that change using git add, then use git restore to see if you can remove your change.

After adding a change, git restore as-is does not remove the staged changes. To check if it did anything, let us look at the output of git status:

OUTPUT 

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

        modified:   mars.txt

Note that if you do not have the same output as above you may either have forgotten to change the file, or you have added it and committed it.

Using the command git restore by itself does not give an error, but it does not restore the file either. Git helpfully tells us that we need to use git restore --staged to unstage the file:

BASH 

$ git restore --staged mars.txt

Now, git status gives us:

BASH 

$ git status

OUTPUT 

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)

        modified:   mars.txt

no changes added to commit (use "git add" and/or "git commit -a")

This means we can now use git restore to restore the file to the previous commit:

BASH 

$ git restore mars.txt
$ git status

OUTPUT 

On branch main
nothing to commit, working tree clean

Understanding Workflow and History

What is the output of the last command in

BASH 

$ cd vampires-and-werewolves
$ echo "Mummies are beautiful and full of love" > mummies.txt
$ git add mummies.txt
$ echo "Mummies are smelly and gross" >> mummies.txt
$ git commit -m "Comment on Mummy hygiene"
$ git restore mummies.txt
$ cat mummies.txt

  1. OUTPUT 

      Mummies are smelly and gross

  2. OUTPUT 

      Mummies are beautiful and full of love

  3. OUTPUT 

      Mummies are beautiful and full of love
  Mummies are smelly and gross

  4. OUTPUT 

      Error because you have changed mummies.txt without committing the changes

The answer is 2.

The command git add mummies.txt places the current version of mummies.txt into the staging area. The changes to the file from the second echo command are only applied to the working copy, not the version in the staging area.

So, when git commit -m "Comment on Mummy hygiene" is executed, the version of mummies.txt committed to the repository is the one from the staging area and has only one line.

At this time, the working copy still has the second line (and git status will show that the file is modified). However, git restore mummies.txt replaces the working copy with the most recently committed version of mummies.txt.

So, cat mummies.txt will output

OUTPUT 

Mummies are beautiful and full of love.

Key Points

  • GitLab has a “History” view where you can explore changes made in prior commits
  • git restore recovers prior versions of files.