Exploring History
Reviewing Changes
As we saw in the 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’ve been adding one line at a time to git.txt, so it’s easy to track our progress by looking, so let’s do that using our HEADs. Before we start, let’s make a change to git.txt, adding yet another line.
nano git.txt
cat git.txt
Output
Git was originally authored by Linus Torvalds in 2005 for development of the Linux kernel
Torvalds said "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
"git" can mean anything, depending on your mood.
I decide to use git to help my work
This is a silly line
Now, let's see what we get.
git diff HEAD git.txt
Output
index 76ab031..f9bb916 100644
--- a/git.txt
+++ b/git.txt
@@ -2,3 +2,4 @@ Git was originally authored by Linus Torvalds in 2005 for development of the Lin
Torvalds said "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
"git" can mean anything, depending on your mood.
I decide to use git to help my work
+This is a silly line
which is the same as what you would get if you leave out HEAD (try it). The real goodness in all this is when you can refer to previous commits. We do that by adding ~1 (where “~” is “tilde”, pronounced [til-duh]) to refer to the commit one before HEAD.
git diff HEAD~1 git.txt
If we want to see the differences between older commits we can use git diff again, but with the notation HEAD~1, HEAD~2, and so on, to refer to them:
git diff HEAD~3 git.txt
Output
diff --git a/git.txt b/git.txt
index 907c125..f9bb916 100644
--- a/git.txt
+++ b/git.txt
@@ -1,2 +1,5 @@
Git was originally authored by Linus Torvalds in 2005 for development of the Linux kernel
Torvalds said "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
+"git" can mean anything, depending on your mood.
+I decide to use git to help my work
+This is a silly line
We could also use git show which shows us what changes we made at an older commit as well as the commit message, rather than the differences between a commit and our working directory that we see by using git diff.
git show HEAD~4 git.txt
Output
commit 7c980e53253b87c7183bf678631e4eee33262957
Author: Duan Ma <[email protected]>
Date: Tue Feb 14 10:35:49 2023 -0500
The original author and date of git creation
diff --git a/git.txt b/git.txt
new file mode 100644
index 0000000..6005f14
--- /dev/null
+++ b/git.txt
@@ -0,0 +1 @@
+Git was originally authored by Linus Torvalds in 2005 for development of the Linux kernel
In this way, we can build up a chain of commits. The most recent end of the chain is referred to as HEAD; we can refer to previous commits using the ~ notation, so HEAD~1 means “the previous commit”, while HEAD~123 goes back 123 commits from where we are now.
We can also refer to commits using those long strings of digits and letters that git log displays. These 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. Our first commit was given the ID 7c980e53253b87c7183bf678631e4eee33262957, so let’s try this:
git diff 7c980e53253b87c7183bf678631e4eee33262957 git.txt
Output
diff --git a/git.txt b/git.txt
index 6005f14..f9bb916 100644
--- a/git.txt
+++ b/git.txt
@@ -1 +1,5 @@
Git was originally authored by Linus Torvalds in 2005 for development of the Linux kernel
+Torvalds said "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
+"git" can mean anything, depending on your mood.
+I decide to use git to help my work
+This is a silly line
That’s the right answer, but typing out random 40-character strings is annoying, so Git lets us use just the first few characters (typically seven for normal size projects):
git diff 7c980e5 git.txt
Output
diff --git a/git.txt b/git.txt
index 6005f14..f9bb916 100644
--- a/git.txt
+++ b/git.txt
@@ -1 +1,5 @@
Git was originally authored by Linus Torvalds in 2005 for development of the Linux kernel
+Torvalds said "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
+"git" can mean anything, depending on your mood.
+I decide to use git to help my work
+This is a silly line
Recover Old Files
All right! So we can save changes to files and see what we’ve changed. Now, how can we restore older versions of things? Let’s suppose we change our mind about the last update to git.txt (the “This is a silly line”).
git status now tells us that the file has been changed, but those changes haven’t been staged:
git status
Output
# On branch main
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: git.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 checkout:
git checkout HEAD git.txt
cat git.txt
Output
Git was originally authored by Linus Torvalds in 2005 for development of the Linux kernel
Torvalds said "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
"git" can mean anything, depending on your mood.
I decide to use git to help my work
As you might guess from its name, git checkout checks out (i.e., restores) an old version of a file. In this case, we’re telling Git that we want to recover the version of the file recorded in HEAD, which is the last saved commit. If we want to go back even further, we can use a commit identifier instead:
git checkout 7c980e5 git.txt
cat git.txt
Output
Git was originally authored by Linus Torvalds in 2005 for development of the Linux kernel
git status
Output
# On branch main
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: git.txt
Notice that the changes are currently in the staging area. Again, we can put things back the way they were by using git checkout:
git checkout HEAD git.txt
Don't Lose Your HEAD
Above we used
git checkout 7c980e5 git.txt
to revert git.txt to its state after the commit 7c980e5. But be careful! The command checkout has other important functionalities and Git will misunderstand your intentions if you are not accurate with the typing. For example, if you forget git.txt in the previous command.
git checkout 7c980e5
Output
Note: checking out '7c980e5'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at 7c980e5... The original author and date of git creation
The “detached HEAD” is like “look, but don’t touch” here, so you shouldn’t make any changes in this state. After investigating your repo’s past state, reattach your HEAD with git checkout main.
It’s important to remember that we must use the commit number that identifies the state of the repository before the change we’re trying to undo. A common mistake is to use the number of the commit in which we made the change we’re trying to discard. In the example below, we want to retrieve the state from before the most recent commit (HEAD~1):

So, to put it all together, here’s how Git works in cartoon form:

Simplifying the Common Case
If you read the output of git status carefully, you’ll see that it includes this hint:
Output
(use "git checkout -- <file>..." to discard changes in working directory)
As it says, git checkout without a version identifier restores files to the state saved in HEAD. The double dash -- is needed to separate the names of the files being recovered from the command itself: without it, Git would try to use the name of the file as the commit identifier.
The fact that files can be reverted one by one tends to change the way people organize their work. If everything is in one large document, it’s hard (but not impossible) to undo changes to the introduction without also undoing changes made later to the conclusion. If the introduction and conclusion are stored in separate files, on the other hand, moving backward and forward in time becomes much easier.
Last updated
Was this helpful?