Recover a lost Git commit using reflog

Before you start

A branch no longer points at a recent commit. Reflog records recent local ref movements, even when that commit is absent from ordinary branch history. It is local, can expire, and is not a backup or a way to recover files Git never recorded.

Use Git 2.28 or newer in a POSIX shell on macOS/Linux, or Git Bash on Windows. Check git --version; Git's installation page covers setup. Each example starts in a new temporary folder. Keep that folder if you want to revisit your work; none of these commands removes your existing projects. The identity and signing settings below apply only to the practice repository.

Work through the example

practice=$(mktemp -d "${TMPDIR:-/tmp}/gitglow-learn.XXXXXX")
sandbox="$practice/project"
mkdir "$sandbox"
cd "$sandbox"
git init -b main
git config --local user.name "Git Learner"
git config --local user.email "learner@example.invalid"
git config --local commit.gpgsign false
printf 'A small project\n' > notes.txt
git add notes.txt
git commit -m "Start notes"

printf 'A valuable local note\n' >> notes.txt
git add notes.txt
git commit -m "Add valuable note"
git reset --soft HEAD~1
git reflog --oneline
git show 'HEAD@{1}'
git branch recovery/valuable-note 'HEAD@{1}'
git log --oneline recovery/valuable-note
git status --short

Check the result

The entry immediately before this exercise’s reset points at Add valuable note. The new recovery branch preserves that commit without moving main or altering the working file. The valuable line also remains staged because this example uses soft reset to reproduce a displaced tip without discarding file content.

Try it yourself

Run git show recovery/valuable-note:notes.txt and compare it with main’s committed version. Decide whether to continue on the recovery branch or apply that commit elsewhere after preserving pending work.

If something goes wrong

In your own repository, HEAD@1 may refer to something different: inspect the message, timestamp, and patch, then use the actual verified commit hash. A failed recovery can mean the reflog expired or the object was pruned. A reflog entry does not recover never-committed untracked content.

Use this workflow in GitGlow

Open the Free read-only Reflog view in History, inspect the entry, and review creating a new recovery branch. Confirm the exact target and a new branch name. This preserves the reviewed object without moving the active branch; recovery is narrower than a universal undo.