I Ran Something and Now My Work Is Gone

Something you committed is not there any more. A command you half understood did something you did not expect, and a piece of real work has disappeared from git log. This is the moment people describe as losing a day.

The commit may still be available even though your branch no longer includes it. This lesson shows how to look for it and recover its work.

Settle the tracked state first

Before recovering the missing work, put the walking guide into a safe starting state. It may still have an unwanted edit in route.txt and a staged scratch.tmp, or you may already have settled those two accidents.

These first commands discard the prepared route mistake, so use them only for this practice project. In your own repository, inspect git status and git diff before discarding any edit you might need.

git restore --staged . first removes staged changes from the next-commit snapshot under the current directory; the dot means this directory and its descendants. Here the terminal starts at the project root, so that covers the project. Then git restore route.txt puts the tracked route back to the newest commit’s version. Neither command deletes scratch.tmp or packing.txt.

git restore --staged .
git restore route.txt
git status

git status may now list scratch.tmp and packing.txt as untracked. Those files do not overlap the missing weather file and can safely remain beside the recovery. There should be no staged change and no modified tracked file.

The work that is missing

The walking guide had a section on the weather in the valley: a few paragraphs about cloud sitting until midday and which forecast to trust. The shell command ls lists the names in the current directory, so use it with the history to look for both the commit and the file:

git log
ls

It is not in the history and weather.md is not on disk. At some point someone ran git reset --hard, which moves the branch back and rewrites the working tree to match. The commit stopped being part of the branch, and by every ordinary means of looking, it is gone.

Git keeps a diary

Here is the part almost nobody is told. Git keeps local logs of recent reference movements. Those records are called reflogs, and plain git reflog shows the recent positions HEAD held in this repository.

git reflog

The newest entry is at the top, so reading from the bottom up tells the repository’s story. If you worked through the preceding lessons, your own amend, reset, and revert activity appears above the older seeded entries. That is useful evidence, not clutter: the reflog records what actually happened in this local repository.

Find the entry labeled commit: Write up the weather section. The seeded reset: moving to HEAD~1 line directly above it is the moment Git walked away from that commit. There may be a newer reset from the earlier private-commit lesson, so the weather label, not merely the word reset, is what identifies the work you want.

Each line begins with a short identifier, and each also carries a name of the form HEAD@{n}, meaning “where HEAD was n moves ago”. The number depends on what you have done in this workspace. Either name on the weather entry identifies that commit.

In this prepared repository, the commit still exists even though no branch points to it. The reflog gives you an identifier you can use to reach it.

Bring it back

You want that commit’s work in your current branch. git cherry-pick takes a commit from anywhere in the repository and applies it to where you are now:

git cherry-pick 3e78e25
git log
ls

That identifier is the one on the line reading commit: Write up the weather section, and it is the same for everyone here because every learner starts from the same seeded repository. In your own projects it will be different every time, so the habit to build is reading it out of your own git reflog rather than remembering it.

git log now shows the weather section back in the history, and weather.md is on disk with its paragraphs intact. It was there the whole time.

What this destroys, and what it cannot

git reflog is pure reading. It changes nothing at all, and you can run it as often as you like. When you are frightened, run it first.

git cherry-pick creates a commit on your current branch without rewriting the commits already in its reachable history. It also leaves the source commit untouched.

Two limits matter. The reflog is local: it describes your repository, not anyone else’s, and a fresh clone has its own. Entries can expire, and repository cleanup can remove commits that are no longer retained. Settings and cleanup affect how long recovery remains possible, so investigate promptly rather than relying on a guaranteed number of weeks. This method also cannot restore edits Git never recorded.

The useful habit is to inspect before making another change. A missing entry in git log is a reason to check git reflog, identify the wanted commit, and recover it while it is still available.

That is the chapter. Six questions, six answers, and one idea underneath all of them: Git adds far more often than it removes, and the things that look destroyed are usually just unreferenced.