git reflog

Definition

The git reflog command records updates made to local references, such as branches, HEAD, and stashes. It allows you to return to commits, including those that are not referenced by any branch or tag. After rewriting history, the reflog includes information about the previous state of references and makes it possible to go back to that state if needed.

There are several git commands that accept a reference parameter (a "ref") to point to a specific commit. The reflog mechanism keeps track of the update history of these refs in the local repository.

The basic usage of git reflog command

Generally, git reflog is used like this:

git reflog

git reflog

It is a shortcut for this:

git reflog show HEAD

git reflog show HEAD

The command above outputs the HEAD reflog. The output looks like the following:

git reflog command

a32556a HEAD@{0}: commit: migrating content
ab371fd HEAD@{1}: commit: adding git reflog outline
23a491a HEAD@{2}: checkout: moving from stage to feature/solver
7b119cb HEAD@{3}: checkout: moving from feature/solver to stage
56a183a HEAD@{4}: commit: changing color scheme
7a2aa71 HEAD@{5}: commit: adding more color palettes
a56322b HEAD@{6}: commit: adding color tool package

Reflog references

By default, git reflog outputs the reflog of the HEAD reference, which points to the currently active branch. You can access a git ref by using the name@{qualifier} syntax.

Execute the following command to get the entire reflog of all references:

git reflog show --all

git reflog show --all

Pass the current branch name to git reflog show if you want to see the reflog for it. In the example below, we display a reflog for the test_branch branch.

git reflog show branch

git reflog show test_branch
#32a591f test_branch@{0}: commit: add snippets
#23bae4a test_branch@{1}: commit (initial): initial commit

Using the command below will output a reflog for a git stash::

git reflog stash

git reflog stash
#0d44de3 stash@{0}: WIP on git_reflog: a567574 adding Vue.js

Timed reflogs

Each reflog entry has an attached timestamp. They can be used as qualifiers in the Git ref pointer syntax, allowing you to filter Git reflogs by time. Here are some examples of time qualifiers:

• 1.minute.ago
• 1.hour.ago
• 1.day.ago
• yesterday
• 1.week.ago
• 1.month.ago
• 1.year.ago
• 2011-05-17.09:00:00

You can also combine time qualifiers (e.g., 1.week.3.hours.ago) and use plural forms (e.g., 5.hours.ago). The refs with time qualifiers can be passed to other git commands, like this:

timed reflogs

git diff master@{0} master@{1.week.ago}

This command shows a diff of the current master branch against master from 1 week ago.

Subcommands of git reflog

Git reflog accepts several arguments that act as subcommands. These are described below.

Show - git reflog show subcommand

The git reflog show subcommand is an alias for git log -g --abbrev-commit --pretty=oneline. It is the default behavior. In the following example, the two commands are equivalent:

git reflog show equivalence

git reflog master@{0}
git reflog show master@{0}

Expire - git reflog expire subcommand

The git reflog expire subcommand is used to clean up old or unreachable reflog entries. Because of the risk of data loss, this subcommand is typically not used directly by users; Git uses it internally. By default, reflog entries expire after 90 days. You can specify a custom expiration time using the --expire argument:

git reflog expire example

git reflog expire --expire=1.day.ago

Delete - git reflog delete subcommand

The git reflog delete subcommand is designed to remove specific reflog entries. End users generally avoid this command due to the risk of data loss, similar to git reflog expire. To delete a specific entry, you can pass its reference:

git reflog delete example

git reflog delete HEAD@{1}

Recovering lost commits

Commits are never truly lost in Git, even during history rewriting operations. Let’s see an example of a git log --pretty=oneline that looks like this:

Recovering lost commits

2b43ceab309da94256db8fb1f35b1678fb74abd4 changes in content
c32557493a95185997c87e0bc3a9481715279351 adding Vue.js
abc234f986d270d7f97c77618314a06f024c4563 migrating content
a5673cd762d8ef2e146d7f0226e81a92f91956b1 adding git reflog outline
2bce4a4404c42128bee8468a9517418ed0ea412 initial commit

Now suppose we commit some new changes to this repository and run the following:

the git reflog command

#make changes to HEAD
git commit -am "API changes"

As a result, the log now looks like this:

git reflog definition

37656e19d4e4f1a9b419f57850c8f1974f871b07 API changes
2b43ceab309da94256db8fb1f35b1678fb74abd4 changes in content
c32557493a95185997c87e0bc3a9481715279351 adding Vue.js
abc234f986d270d7f97c77618314a06f024c4563 migrating content
a5673cd762d8ef2e146d7f0226e81a92f91956b1 adding git reflog outline
2bce4a4404c42128bee8468a9517418ed0ea412 initial commit

At this stage, in order to make an interactive rebase against the master branch, we need to execute the following:

git reflog example

git rebase -i origin/master

While rebasing, the s rebase subcommand marks commits for squashing into the most recent "API changes" commit. As a result of squashing the commits, the git log output now looks like this:

git reflog usage

40d8a1237656e19d4e4f1a9b419f57850c8f1974 API changes
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit

It now seems that the squashed commits are gone. If you need to operate on a squashed commit, you can leverage the reflog.

git reflog description

git reflog
37656e1 HEAD@{0}: rebase -i (finish): returning to refs/heads/git_reflog
37656e1 HEAD@{1}: rebase -i (start): checkout origin/master
37656e1 HEAD@{2}: commit: API changes

There are reflog entries for the start and finish of the rebase, and preceding those is the "API changes" commit. The reflog reference can be passed to git reset in order to reset to a commit before the rebase.

git reset HEAD

git reset HEAD@{2}

This command will move HEAD to that commit with "API changes", and restore the other squashed commits.

Practice