Git reflog: The Git reflog or Reference Logs is a rare command that is used to record logs when certain branches along with references were once updated in the local repository. Git reflog is specifically used to specify the references of old values. In a nutshell, it brings lost commits out from the grave. It also points to the branch which you might have once updated in your local repository to carry out specifically required operations.

Git reflog

Reflog is also known as Git’s safety net. It is generally used to trace down every change you make in your repository regardless of whether you have made a snapshot of committed your workflow or not. You may assume it as the history of chronological activities you might have carried out in your repository. To run the git reflog command, you type the following command:

The above should output something like this:

The above output can be translated as follows:

  1. The HEAD {0} shows movement of your activity to master branch with HEAD value 2.
  2. You next amended a commit message.
  3. You merged the branch to master before committing a snapshot.
  4. You successfully merged your HEAD~2.

The above syntax associated with HEAD is used to let you understand the reference commit you stored in the reflog. In the above output the HEAD~2 simply means that Git reflog will from the previous section, but it will not commit history. Rather it will refer to the entry.

Associated options with reflog

The above command is used to reflog the reference processes.

The above command is associated with –all in the sense that when the –all command is specified, the reflog will process all the working trees. By default, this action will limit the processing of reflog only from the present tree put on the move.

As already discussed, the prune command executes the older entries under a specified period. Therefore, executing this command will configure the expiration time which in turn would specify the time duration say 30 days regardless of all the prune entries made in between. It would take into consideration the default options regardless of the age or time and turns off the pruning of the reachable entries.

The above command acts similar to what is discussed with the prune command before it. Since the older entries are generally not shown with time, this command will display unreachable pruned entries older than the given time from the current branch tip. Although, not specifying the expiration time is taken as 30 days by default. One important that is important to take note that all pruned unreachable entries never turn off.

The above command is used to update the top value of the reflog entry that is taken into reference if and only if the previous top entry was pruned. This command does not take into consideration the ignored symbolic references.

The above command acts as a predecessor of pruned entries. It simply compares the old entries to the new entry fields. For instance, consider “SHA-2” if found equal in both old and the new entry fields, it precedes it.

The above command prunes all the entries that point to the broken commits. A broken commit is the commit that is not reachable from any tips or references indirectly or directly. To ascend this, the traversing takes place for all the reachable object commits which have the same cost as the pruning. The main intention of using this command is to fix the corruption associated with the garbage collection which is found in the older versions and is unprotected by the reflogs.


The above command does not prunes the entries rather it displays what entries are pruned so far.

The above command associated with reflog is used to display additional information on the screen.


In this tutorial, you learned how to use reflog along with different options. These options have been coded to deliver you the best practices for your projects. Therefore, you can now conclude that git reflog is primarily used to refer to commits that are not available by any means. It is indeed a great command to recover those unreachable commits out from the grave.

Additionally, you also learned to pick out the exact commit you need in any of your development scenarios. It is quite easy to leverage Git reflog along with common aspects of commands that alter its workflow.

Pin It on Pinterest

Share This