Reflog vs. Log: How to Use Git Reflog

Git log and git reflog are two similarly named components that give developers an opportunity to look into the repository’s commit history through the command line. Those useful commands are usually confused or misunderstood among the many Git commands. In this article, you will get to know the differences between git reflog vs. git log.

What is git log?

Committed snapshots are displayed by the git log command. It’s used to list and filter the project’s history, as well as to look for specific modifications. In comparison to git status, which controls the working directory and the staging area, git log only operates on the committed history while presenting a repository’s history in a searchable way.

The git log output shows the view of the repository’s commit history, providing a detailed record of the project’s history, including all commits made to the currently active branch. This command displays information such as commit hashes, authors, dates, and messages, which helps users list and filter the project’s history or look for specific modifications. Keeping track of changes is important for your Git internally. For example, you can view the branch history of the master branch to see all changes merged into it.

In a nutshell, the git log command is helpful while looking over the history of a repository and locating a specific version of a project.

What is git reflog? 

The git reflog command is a mechanism that records updates to the tips of branches and other branch references in your repository, offering a detailed log of your local operations and local commits. This includes commits, resets, and merges, serving as a safety net to recover lost commits.

The reflog is strictly local and isn’t part of the repository. It’s also not included in pushes, fetches, or clones. Git uses the git reflog command to keep track of changes made to branch tips. It lets you go back to any commit, even if it isn’t referenced by any branch or tag. Following the rewriting of history, the reference logs contain information about the former state of branches, which allows you to revert to that state if necessary.

Project version control with reference logs

The currently active branch is called HEAD, showing all recent reference movements like branch switches, git rebases, git resets, and commits. In Git, a “ref” (short for reference) is a named pointer to a specific commit, such as HEAD, main, or refs/heads/feature-x. These references are used in many Git commands to specify which commit or branch to operate on. For example, when you run commands like git checkout HEAD~1 or git reset main, you’re instructing Git to act on a particular ref. References are a core concept in Git’s version control system and are recorded and updated internally with every operation that changes the repository state.

You may keep track of the update time of git references in the local repository using this mechanism called reference logs. There are several git reflog subcommands like git reflog show, git reflog expire, git reflog delete, and verify for managing reflog history. The git reflog list command can be used to display all references with a reflog, helping you identify which references are associated with the given reflog entries data.

When referencing commits, you can use git ref pointer syntax (e.g., @{0} or @{1.day.ago}) to access specific points in the local reference history. The reflog is stored within the local repository’s .git directory — specifically in .git/logs/refs/heads/ for individual branches and in .git/logs/HEAD for tracking changes to the HEAD reference. This means all reflog entries are maintained locally and not shared with or accessible from remote repositories.

Git reflog expire command

Over time, Git repositories accumulate old reflog entries or unreachable reflog entries, which may need to be cleaned up to maintain repository hygiene. Git manages this automatically using the git reflog expire command, which removes outdated or unreachable entries based on expiration policies. For more targeted cleanup, you can manually delete specific git reflog entries using the git reflog delete subcommands. It’s important to note that while git handles most of the expiration and pruning internally, especially for unreachable entries, you can manually intervene for precise control over reflog history.

Summing it all up

Git reflog does not include remote-tracking branches (like origin/main) unless explicitly fetched or acted upon locally. Reflog entries keep track of when git references in the local repository were modified. A separate git reflog is kept for the git stash, in addition to branch tip git reflogs. Reflogs are kept in folders under the .git directory of the local repository. 

Git reflog vs. git log put into perspective

The most significant difference between git reflog vs. log is that the log is a public record of the repository’s commit history, whereas the reflog is private. After a push, fetch or pull, the git log is duplicated as part of the git repository. The git reflog, on the other hand, is not included.

The reflog exists as a file located in .gitlogsrefsheads with the reflog history of local commits for a specific branch and excludes any commits that may have been trimmed away by git garbage collection processes. The git log, on the other hand, offers a historical traversal of commits for a branch that begins with the most recent commit and concludes with the very first commit in the branch’s history.

While git reflog helps you recover lost commits and deleted branch tip reflogs, it does have certain disadvantages. Reference logs, for example, are saved locally, so they can’t be pushed or pulled from a remote repository. To preserve disk space, reflog entries usually expire or are wiped after a specific period.

Executing git reflog command

Basic Git actions like commit, branch, reset, rebase, and git merge are included in the reflog. The most basic git reflog example use case is invoking: “git reflog”

You may need to backtrack your route if you make adjustments while working along or across branches. To undo the modifications, several commits are used, including the most damaging ones like the reset command.

There are three steps to the git reset command: hard, soft, and mixed. A hard git reset clears the disk of all commits and linked files. The soft git reset restores the HEAD to the index, whereas the mixed reset restores the file to its original state. Say, if you delete a branch accidentally, use git reflog to effectively recover the deleted branch: find the last commit hash of the deleted branch and recreate it.

How to restore deleted branches?

Let’s imagine you had the main branch and then used the command “git branch example1” to create a new branch named example1. Then you used “git branch -d example1” to mistakenly remove this branch. At this point, you either quickly recognize the error (for example, deleting another branch instead of the desired one) because that was the last action you took in your terminal, or you don’t know you deleted the wrong branch at all until later.

So, run the command ‘git checkout sha value>’. This command will direct the HEAD to the commit with the supplied SHA value. This will result in the previously mentioned disconnected HEAD condition.

Execute the command ‘git checkout -b branch name>’ after that. The HEAD pointer will point to the new branch, which will be created from that commit.

If you’ve misplaced the message, use ‘git reflog’ to locate the SHA of the commit that was at the end of the deleted branch. Make sure your commits are correctly named so you can discover them quickly.

How to restore commits? 

The procedure for restoring a deleted commit is rather straightforward. All you have to do is use “git reflog” to get the SHA value of the commit you want to revert to, and then run ‘git reset —hard’. Remember that this command will erase any modifications to your working directory that have not yet been committed, so use it with caution.

You have other options at your disposal – git revert or git restore commands and of course professional backup solution. The trend is new, but there are already exceptional solutions available. So, check it out.

[FREE TRIAL] Ensure compliant DevOps backup and recovery of your fintech and banking data with a 14-day trial 🚀
[CUSTOM DEMO] Let’s talk about how backup & DR software for DevOps can help you mitigate the risks in one of the most targeted industries

Frequently Asked Questions

What Git command shows who made changes to each line in a specific file?

git blame <filename>

It displays the last commit for each line in a specified file, including who made each change and when. The command helps track the origin of specific lines in a file, which can be useful when debugging or understanding code history.

How to view the difference between the two Git branches?

To compare two branches, use the git diff command, specifying the branch names.

git diff <branch1> <branch2>

The line will show changes in additions and deletions between the two branches. You can add –stat for a high-level view of changed files and lines if you want a summary.

git diff --stat main feature-branch

This command will compare the main branch with the feature branch and provide a summary (output). For example:

file1.txt		| 4 +++-
file2.js		| 10 +++++-----
folder/file3	| 2 +-
3 files changed, 12 insertions(+), 4 deletions(-)

Should I use Git tags or branches for releases?

Use tags for release points as they serve as permanent references. Branches can be used for ongoing work or hotfixes

Tags are ideal for marking release points in your repo. They are lightweight references that don’t change over time. Tags, especially annotated ones, are often used for stable releases, such as v1.0, v2.0, etc.

Branches, however, are mutable and designed for ongoing work. A release branch can help maintain a minor version, like patching older versions without affecting newer work. Nonetheless, branches are not as final as tags, as they can be merged or deleted.

Does Git have a log file?

Git doesn’t maintain a traditional log file. Yet, the history of commits may serve as its log. You can use git log or git reflog commands to get necessary commit histories. For detailed trace logs, enable Git’s debug logging:

GIT_TRACE=1 git <command>

It will provide a trace log for specific Git commands in the terminal.

What is the difference between log and diff commands?

In short, log is for viewing commit history, while diff serves for viewing differences between snapshots.

The git log shows:

• history of commits
• commit messages
• author details
• timestamps for a branch or range of commits.

As for git diff, it compares differences between:

• commits
• branches
• files
• specific working states.

In turn, it provides a line-by-line breakdown of changes.

The article was originally published on March 9th, 2022