Recovery before reset
Create a save point before history repair.
git reflog
25 min read, 30 min lab
operator
`git reflog` records where your branch and HEAD have been locally. `stash`, backup branches, and reflog are recovery tools. `reset --hard` discards work; it should never be a reflex.
A rebase went wrong and you need to return to the previous branch state.
Worked command
$ git branch backup-before-repair$ git reflog --date=local -n 8$ git reset --hard HEAD@{1}$ git log --oneline --graph -n 8
Do not reset hard before preserving a backup branch or stash when work may matter.
Make a save point, inspect reflog, then repair.
After a bad rebase, what does `git reflog` let you recover that `git log` on the branch will not show?
Show the answer
Correct: A. Prior positions of HEAD and the branch, including commits no longer on any branch
Reflog records every local move of HEAD and the branch, so you can return to a pre-rebase state even when those commits are no longer reachable from the branch tip. It tracks committed positions only, not unstaged working-tree edits, which is why a backup branch or stash is still the first save point.
Practice checklist
- Create three commits in a disposable repo.
- Make a backup branch.
- Use reflog to identify a previous state.
Deliverable evidence
- Backup branch name, reflog entry, and final graph.
shows: The states work passes through (working tree, index, commit/branch, remote), the commands that move it between them, and reflog as the local-only save-point net that reset --hard can otherwise destroy.
does not prove: It does not prove your repository is recoverable: reflog only protects commits Git has actually recorded, so unstaged or untracked working-tree changes wiped by reset --hard are not in scope and stay gone.
Commit these to memory, then drill them until recall is automatic.
cue A rebase went wrong; before repairing, you need to find the previous local HEAD position to return to.
show recall target
git reflog