Undoing Changes

Throwing away an edit

You changed a file and want it back the way it was. git restore replaces your working copy with the staged version, or the last committed one if nothing’s staged ¹:

me@linuxbox:~/garden$ echo oops >> beds.txt
me@linuxbox:~/garden$ git restore beds.txt
me@linuxbox:~/garden$ git status -s
me@linuxbox:~/garden$

This is one of the few git commands that can destroy work. An edit you never committed or staged isn’t stored anywhere else, so once it’s overwritten it’s gone ². Run git diff first to see what you’d lose. git status even prints this command as a hint, so take a second before pasting it. git restore . does every file at once.

(Older guides use git checkout -- file for the same job. Git 2.23 split git checkout’s two jobs into git switch, for changing branches, and git restore, for restoring files ³.)

Unstaging

You git added something that doesn’t belong in the next commit. git restore --staged takes it back out of the staging area and leaves your edit alone ¹:

me@linuxbox:~/garden$ git add beds.txt README.md
me@linuxbox:~/garden$ git restore --staged README.md
me@linuxbox:~/garden$ git status -s
M  beds.txt
 M README.md

Nothing is lost; README.md is just unstaged again.

An older version of a file

To bring back a file as it was in any earlier commit, add --source ¹:

me@linuxbox:~/garden$ git restore --source=HEAD~3 beds.txt     # as it was three commits ago
me@linuxbox:~/garden$ git restore --source=adc6083 README.md   # as it was in that commit

It changes only your working copy; commit it if you want to keep the old version. (HEAD~3 means “three commits before the current one” ².)

Fixing the last commit

Forgot a file, or made a typo in the message? git commit --amend replaces the last commit with a new one made from the staging area ²:

me@linuxbox:~/garden$ git commit -m "Plan the fence"
me@linuxbox:~/garden$ git add fence-posts.txt                # forgot this one
me@linuxbox:~/garden$ git commit --amend --no-edit           # same message, now with the file
me@linuxbox:~/garden$ git commit --amend -m "Plan the fence and posts"   # or reword it

Amending doesn’t edit the old commit; it makes a new commit with a new ID and drops the old one from your branch ². That’s harmless for commits only you have. Only amend commits you haven’t pushed: if someone else already has the old commit, amending and force-pushing causes them real trouble ².

Undoing a shared commit

To undo a commit that’s already been shared, don’t rewrite history; add to it. git revert creates a new commit that does the opposite of an earlier one ⁴:

me@linuxbox:~/garden$ git revert --no-edit HEAD
[main d758bab] Revert "Add lettuce"
 1 file changed, 1 deletion(-)
me@linuxbox:~/garden$ git log --oneline -3
d758bab Revert "Add lettuce"
11bf533 Add lettuce
3ce82ab Describe the beds in the README

The mistake and its reversal both stay in history, with a message saying so, and everyone’s copies stay consistent. Revert any commit by ID, not just the last one ⁴.

Stop tracking a file

To remove a file from the repository but keep it on disk, git rm --cached, then add it to .gitignore so it isn’t added again (last lesson) ².

Committed work is hard to lose

Notice the pattern: the commands that can lose work act on uncommitted changes. Once something is committed, git keeps it, even after amending, and module 5 shows how to get back commits you thought you’d thrown away ². So commit early and often, even messy work in progress; you can tidy it up later.

Your turn

So

git restore throws away uncommitted edits (carefully), --staged unstages, and --source brings back any old version. git commit --amend fixes the last commit before you push it; git revert undoes a shared commit by adding a new one; git rm --cached stops tracking a file. Commit often: committed work is hard to lose.