Skip to content
Related Articles

Related Articles

Using Refs and Reflogs in Git
  • Difficulty Level : Expert
  • Last Updated : 15 Dec, 2020

Git reference (Git ref) is just a file that contains a git commit’s SHA-1 hash. The most direct way to reference to a commit is via its SHA-1 hash, this acts as a unique ID for each commit. In order to refer to a commit you have to remember it’s SHA-1 hash value, so instead of remembering the SHA-1 hash value you can use git ref which is easy-to-remember rather than hash. We can say a ref is an indirect way of referring to commit, you can think of it as a user-friendly alias for a commit.

Refs are stored as a normal file text in .git/refs directory. To explore refs in one of the project’s repositories navigate to .git/refs or type the following command in Git bash in the root directory of your project.

$ ls -F1 .git/refs

or type the command in Git bash in the root directory of your project

find .git/refs



You should see the following structure, but it will contain different files depending on what branches, tags and remotes you have in your repo.

$ ls -F1 .git/refs

 heads/

 master

 remotes/

 tags/

All local branches of repository are defined in refs/heads/ directory. Each file name matches names of the corresponding branch, and inside file, you will find a commit hash. This commit hash is the location of the tip of the branch.



Reflogs

Git keeps track of updates to the tip of branches using mechanism called Reference Logs or “reflogs”. In addition to branch tip reflogs, a special reflog is maintained for the Git stash. To explore git reflogs navigate to .git/logs/ref/heads and also git/logs/ref/stash(if git stash has been used on the repo).

reflogs record when tips of branches and other branches were updated in local repositories. Reflogs are useful in various Git commands, to specify the old value of a reference. For example, HEAD@{2} means “where HEAD used to be two moves ago”.

$ git reflog HEAD@{2}

$ git reflog

This command manages information recorded in reflogs. The command takes various subcommands, and different options depending on the subcommands. Below are some and most used subcommands in reflogs.

git reflog [show] [log-options] [<ref>]

git reflog expire [–expire=<time>] [–expire-unreachable=<time>]

                            [–rewrite] [–updateref] [–stale-fix]

                           [–dry-run | -n] [–verbose] [–all [–single-worktree] | <refs>…​]

git reflog delete [–rewrite] [–updateref]

                            [–dry-run | -n] [–verbose] ref@{specifier}…​

git reflog exists <ref>

Words in square brackets such as “show”, “log-options” are qualifiers, or we can say arguments to git reflog command.  

  • Git Reflog Show: The “show” subcommand (which is also default, in absence of any subcommand) shows logs of the reference provided in command(or HEAD, by default). The reflog covers all recent actions, and in addition HEAD reflog records branch switching.
  • Git Reflog Expire: The “expire” subcommand prunes older reflog entries. Entries older than “expire” time, or entries older than “expire-unreachable” time and not  reachable from the current tip, are removed from the reflog. This is typically not used directly by end users
  • Git Reflog Delete: The “delete” subcommand deletes single entries from the reflog. Its argument must be an exact entry (e.g. “git reflog delete master@{2}“). This subcommand is also typically not used directly by end users.
  • Git Reflog Exists: The “exists” subcommand checks whether a ref has a reflog. It exits with zero status if the reflog exists, and non-zero status if it does not.
My Personal Notes arrow_drop_up
Recommended Articles
Page :