reflog is git’s internal ‘last resort’ if you’ve lost a commit during a rebase (or something else equally scary).
If you run it on our workshop git repo, you should see the intermediate steps in the interactive rebase we did a few pages ago:
git reflog
4a91d30 (HEAD -> branch) [email protected]{0}: commit (amend): testing file
db94c2f [email protected]{1}: commit: testing file
ea54536 [email protected]{2}: rebase -i (finish): returning to refs/heads/branch
ea54536 [email protected]{3}: rebase -i (pick): rename to file
7b4f35b [email protected]{4}: rebase -i (pick): added important file
e58222c [email protected]{5}: rebase -i (squash): thirdcommit
c890001 [email protected]{6}: rebase -i (start): checkout HEAD~4
7c39e9e [email protected]{7}: rebase finished: returning to refs/heads/branch
7c39e9e [email protected]{8}: rebase: rename to file
5fd910b (master) [email protected]{9}: rebase: checkout master
335d198 [email protected]{10}: commit: rename to file
Say we wanted to get one of these back, or revert back to a state that isn’t screwed up - we just checkout that revision using it’s ref
git checkout 7c39e9e
It’ll warn you to the fact you’ve now have a DETACHED_HEAD ref
Note: checking out '7c39e9e'.
You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout.
To save this state, simply make a new branch, and then you can treat it as any other branch
git checkout -b undo-bad-thing
And then bam, you’ve got it back - magic!
Okay enough of logs, let’s make friends by blaming other people for commits.