Reflog • GitHub & Git Foundations

Git tracks all of the revisions
that you make to your software.

But did you know that with reflog

it also tracks the revisions
to your revisions?

♪ (smooth music) ♪

Users of Git first discover

that every commit
they make in a repository

is a recorded snapshot in time

that shows how
the code base is progressing,

but more advanced users of Git
discover that the reflog

is keeping track of commits that are made,

as well as commits that are discarded.

This provides a rolling buffer of 30 days

in which you can recover
from any mistake,

including detrimental ones
with the git reset command,

the deletion of a branch,

or possibly a rebase gone awry.

♪ (music) ♪

Git reset is specific
to each and every branch.

You'll notice, if you chose to inspect,

that in the .git folder

there's a subdirectory called logs.

Beneath there is a file
specific to every branch

that you have on your local repository.

Each of those logs is keeping track
of the changes that you make,

both forward and backwards in direction.

The user interface to this
is the git reflog command.

It outputs the most recent history.

A paging mechanism allows you
to go through older entries

that have transpired on the branch
that you're currently checked out to.

Once you've run git reflog
for the first time

and seen the historical events
that displays on screen,

you wonder what can you do with those.

Simply grab one of the seven
character hashes that are displayed

and use that as a potential candidate
for restoring your code base.

git reset --hard
to that hash.

The current branch
is now forcefully switched

back to that historical point.

♪ (music) ♪

The linear history
that git reflog provides

can be difficult to navigate.

Which one is an orphan branch?

Which one is a commit
that's no longer part of this code base?

A little bit of command line
hackery and creativity

can pipe the result of reflog
over into a graphical user interface

such as gitk,

thus making it easy to see
which branches are out on their own,

which commits are no longer
part of this branch,

and which things
you might want to recover

by capturing their hash

and using the reset --hard
as described a minute ago.

♪ (music) ♪

Git reflog is your motivation
to make frequent commits.

Making frequent commits
means there's history stored in reflog

whether or not you reset them away,
discard a commit,

potentially amend it, and make a mistake.

Everything that's not committed,
either in the working directory

or the staging area is at risk,

but if it's committed, you can recover it.

Those last 30 days
have an insurance policy

and allow you to take big, bold steps

with the use of other Git features.

♪ (music) ♪

Thanks for watching this episode
of Git and GitHub Foundations

on the reflog.

Be sure to subscribe
to our channel over here,

or if you have questions
on how to use that effectively,

ask those down below.

There are related episodes
such as the one on reset

that really are helpful to watch

in concert with what
you've just learned on reflog.

♪ (music) ♪