Here’s a quick rundown on reflog for us kooks.

  1. It’s ref-log, not re-flog.
  2. It’s Git’s history.
  3. If you bonehead something, you can use the reflog to retrieve it (for a while. Eventually entries expire).

Usually people learn new aspects of Git in panic mode, trying to get something else done. If you’re learning reflog like this, I’m sorry. Ha! I’ve been there, though. Just keep randomly executing snippets from Stack Overflow and everything will probably work out in the end.

If you are super cool, though, which is pretty clearly the case, you’re proactively learning instead of desparately trying to salvage 2 days of work you just tanked. You are in a calm receptive state. Great! Now is a good time to see a simple example and learn about reflog on our terms.

Demo

I’m going to use glitter and a new repo to demo a great use case for reflog.

Whoops

one I branched from master to develop and made 3 commits. Then I forcefully deleted develop before merging.

Git tried to warn me, but I was young and stupid. Now these precious commits are gone.

bdd6580 (HEAD -> develop) Add four nasty Phosphorus
a4745cb Add six red Dysprosium
6f78f8d Remove eight nasty Lanthanum

Oh, wait. No they aren’t.

two I can see the commits in the reflog.

Pluck It

three And look at that. It’s exactly the same as that branch I threw away a second ago.

This is a very simple example. Reflog can also be used diagnostically to figure out what the hell you did when you get in a weird state. It shows when you change branches, when you merge, rebase, etc. There’s all sorts of other stuff to look at, but this should at least leave you more familiar with it.