I Changed a File and I Want the Old One Back

You have a repository with a few commits in it, you changed a file, and the change was wrong. That file’s change is neither committed nor staged. You just want the file back the way it was.

This is the most common undo there is, and the good news is that it is also the safest, because Git already has a copy of the old version.

Look before you touch anything

The repository in your terminal is a small walking guide. Someone has been editing it. Start by asking Git what is different:

git status
git diff

git status groups what is staged, what is changed but not staged, and what is untracked. It does not show you the changed lines, and before undoing anything you want to see those.

git diff is the command that shows it. It prints the changed lines, marking each with a - if it was there before and is going away, or a + if it is new. A file with no changes produces no output at all, which is why an empty answer from git diff is a useful answer.

Chapter 3 read diffs between two saved commits. Run with no commit names, as here, git diff compares the working tree with the staging area. Nothing about route.txt is staged, so its staged version still matches the newest commit and this diff shows the unwanted edit. That is as much as you need to undo it safely.

You should see that route.txt has had its distance changed from 11km to 110km. That is the mistake. It is a real walking route, and 110km is not a day out.

Put the file back

The command is git restore, and its job is to overwrite the file in your working tree with a known-good copy Git already holds.

Which copy is worth one sentence, because it catches people out later. By default git restore takes the version from the staging area. Here nothing about route.txt is staged, so the staged version still matches the newest commit and restoring it puts back the committed version. Once you start staging work in progress, they stop being the same, and the option --source lets you say which one you meant.

git restore route.txt
git status
git diff

git restore route.txt names the one file to put back. The second git status should no longer mention route.txt, and git diff should print nothing at all, because there is no longer any difference to show.

What this destroys, and what it cannot

Be clear-eyed about this one, because it can genuinely throw uncommitted work away.

git restore discards your uncommitted change to that file, permanently. The 110km edit is not in a commit, so Git never had a copy of it, and no later lesson in this chapter can bring it back. That is the trade: you get the old version because you are giving up the new one.

What it cannot do is damage your history. It does not touch commits, it does not move any branch, and it only affects the paths you name. A file you do not name is left alone.

The rule worth carrying: git restore is safe for committed work and final for uncommitted work. If you are unsure whether you want the change gone, git diff first and read what you are about to lose.

Next: the same situation, one step further along, when the thing you want to undo has already been staged.