LinuxCommandLibrary

git-reflog

Recover lost commits or branch states

TLDR

Show the reflog for HEAD

$ git reflog
copy

Show the reflog for a given branch
$ git reflog [branch_name]
copy

Show only the 5 latest entries in the reflog
$ git reflog [[-n|--max-count]] 5
copy

SYNOPSIS

git reflog [show] [options] [ref]
git reflog expire [options] [--all]
git reflog delete [options] [--all] [reflog_entry]

PARAMETERS

--all
    For expire and delete subcommands, process reflogs of all references. For show, show all reflogs (equivalent to --walk-reflogs --all).

-n <count> or --max-count=<count>
    Limit the number of reflog entries to show for the show subcommand.

--relative-date
    Show dates relative to the current time (e.g., "2 weeks ago").

--date=<format>
    Specify the date format (e.g., 'local', 'iso', 'rfc2822', 'short', 'raw').

--expire=<time>
    For expire, prune reflog entries older than the specified time. Defaults to `90 days` for reachable entries and `30 days` for unreachable.

--expire-unreachable=<time>
    For expire, prune unreachable reflog entries older than the specified time.

--stale-fix
    For expire, prunes entries that point to non-existent objects.

--dry-run
    For expire or delete, don't actually modify the reflog; just show what would be done.

--rewriter
    Used with expire to filter which entries are considered.

--no-color
    Turn off colored output.

--color[=<when>]
    Turn on colored output.

DESCRIPTION

The git-reflog command is a powerful utility for viewing and managing the reflog, which is a local, chronological record of every change made to the tip of branches and other references in your repository. Unlike the commit history, which records actual commits, the reflog tracks actions like commits, checkouts, merges, resets, and rebases, even if they don't create new commits or if a commit is temporarily "lost" from the branch's history.

It acts as a safety net, allowing you to easily recover from operations that seem to have lost commits or moved your HEAD to an undesired state. For example, if you accidentally reset a branch or rebase incorrectly, git-reflog can show you the previous state of your HEAD or branch tip, enabling you to use git reset or git checkout to revert to a prior entry. Each entry in the reflog corresponds to a point in time when the reference was updated, along with a timestamp and the action that caused the update.

CAVEATS

Reflogs are strictly local to your repository; they are not part of the shared history when you push or pull. Therefore, they cannot be used to recover work lost by others or to restore a branch on a remote server. Reflog entries are also subject to automatic expiration and pruning. By default, entries older than 90 days are pruned if they are reachable, and unreachable entries are pruned after 30 days. This means very old or long-lost changes might eventually be removed.

SUBCOMMANDS OF GIT-REFLOG

  • show: This is the default subcommand if none is specified. It displays the reflog of the specified reference (or HEAD by default). You can provide a specific reference like main or HEAD. Output format is similar to git log.
  • expire: Used to prune old or unreachable entries from the reflog. This is often run automatically by Git's garbage collection (git gc). You can manually control the expiration policy.
  • delete: Allows you to manually delete a specific entry from the reflog. This is a more drastic operation than expire and should be used with caution, typically after verifying with show and dry-run.

REFLOG ENTRY FORMAT

Each reflog entry shows the old and new commit SHAs, the committer identity, a timestamp, and a message describing the action that caused the reflog update. For example: <old_sha> <new_sha> <committer> <timestamp> <action_message>. The action message is often very descriptive, like commit: initial commit, checkout: moving from main to feature, or rebase: aborting rebase. These messages are crucial for understanding the context of each change.

HISTORY

The concept of a reference log (reflog) has been an integral part of Git since its early development. It was designed by Linus Torvalds to provide a robust safety net for local operations, allowing users to recover from various mistakes that might otherwise lead to data loss. The `git-reflog` command has been a stable and core component of the Git suite, evolving primarily in its options for filtering and managing reflog entries rather than its fundamental purpose. It underscores Git's philosophy of making it hard to accidentally lose data.

SEE ALSO

Copied to clipboard