The Git Reflog — Your Hidden Lifeline

We've all had that feeling... Did I just delete a month's work? 🤯 😱

Just the thought of it probably gives you the creeps. Fear no more! Git got you covered, particularly the reflog, which has saved my bacon numerous times. After all, Git is your super backup with "undo" on steroids!

Git is your super backup with "undo" on steroids!

In this post, you'll learn what the reflog is and how to interpret it. For my members, I'll also show how it can be used to recover "lost" work, such as deleted branches and commits.

(Not a member yet? Don't worry, you can always sign up when you get there.)

What is a reflog?

In Git, the reflog is a log that keeps track of changes made to the tips of branches and other reference points (such as stashed changes) in a local repository. The term reflog is the short form for reference log.

You can think of the reflog as your web browsing history if we consider your local repo as the internet and Git as your browser. Hence, navigating back to a previously visited page, or for that matter, a closed tab, is a no-brainer – just like digging out deleted branches or commits from the reflog!

The reflog records when a branch or other reference is updated, and includes changes made explicitly by you and changes implicitly made by Git, such as actions performed during a rebase or merge.

A reflog is listed as a stack, just like the regular commit log, with the most recent action performed at the top.

The reflog can be helpful for:

Recovering lost commits: If you accidentally delete a commit or branch, you can use the reflog to find the now orphaned commit and recover it.
Undoing changes: If you change a branch or commit and later decide to undo it, you can use the reflog to find the previous state of the branch or commit.
Debugging: The reflog can be used to diagnose issues that may arise from changes made to a branch or commit.

It's important to note that the reflog only tracks changes in your local repository and is not shared with remote repos or other developers.

💡

Orphaned commits are all commits in your local history that are not directly or indirectly accessible from a named reference such as a branch, tag, or HEAD. They'll eventually be discarded completely when Git garbage collects.

Finally, the reflog is, in fact, reflogs since Git keeps separate records for each reference. Technically all reflogs are stored inside .git/logs where each reflog is a plain text file named like the reference it's tasked to record. The default reflog, however, is the one recording changes made to HEAD, which 99% of the time is what you'll ever be using when looking for "lost" work.

To view your own HEAD reflog, just type $ git reflog, or to view the reflog of a branch use $ git reflog show <branch>.

What is HEAD in Git?

HEAD answers the question: Where am I right now in the repository? It is a pointer to the currently checked out branch or commit, which in turn contains an immutable snapshot of your entire code base at a given time.

The Pragmatic GitAlexis Määttä Vinkler

Are you not 100% sure what HEAD is? Take a breather and check out this post!

Saving your bacon

As mentioned, Git is your super backup with "undo" on steroids. That's because Git never really loses anything, even when you intentionally (or accidentally) rewrite history.

Let's consider two common cases and see how they can be recovered from by using the reflog:

Recovering a deleted local branch (not yet pushed to remote)
Reverting a completed rebase (with a troublesome outcome)