LuisLlamas Logo
descartar-cambios-en-git-con-restore

Discarding Changes with Git Restore

  • 4 min
  • Intermediate

The git restore command is the command for discarding or undoing local changes in the working directory and removing files from the Staging Area.

During development, sometimes you make modifications that you ultimately don’t want to keep. You’re editing a file, you start changing things, you test a crazy idea, and in the end, you don’t like what you changed.

Whether you’re experimenting or you’ve made a mistake, we need a way to revert a file to its previous state. We need a “Ctrl+Z”, but for Git.

In this article, we’ll see how to use this git restore to discard changes in our working directory or remove files from the Staging Area.

In the past, this task was done with git checkout, a command overloaded with functions that often caused confusion.

To solve this, modern versions of Git introduced git restore.

Discarding local changes

This is the most common case. I’ve broken the file, I want to go back. You don’t want your current version of the file, you want it to be identical to the last commit again.

The command is:

git restore nombre_archivo.ext
Copied!

You can also use . to restore all modified files in the current folder:

git restore .
Copied!

Git goes to its database (the last commit), finds that version of the file, and copies it to your Working Directory, overwriting whatever you had written.

Be careful! This operation is destructive. Unlike other things in Git, with restore there is no undo. If you restore a file that you hadn’t saved with a commit, the changes you had written in it are lost forever.

Restoring from the past

git restore isn’t just for going back to the “last” state. You can bring a file exactly as it was 5 months ago.

Imagine you deleted a function in utils.js 10 commits ago and now you need it back. You don’t need to revert the whole project. You can restore only that file from a specific commit:

git restore --source c5f23a1 utils.js
Copied!
  • --source: Indicates the hash of the commit (or branch name) from where we want to copy.
  • utils.js: The file we want to recover.

This will bring that old version of the file to your current working directory, ready for you to use.

The problem with the old git checkout

If you look for Git tutorials from before 2019, you’ll see that to discard changes in a file they tell you to use:

git checkout -- nombre_archivo.js
Copied!

The problem was that git checkout suffered from multiple personality disorder. It did two totally different things depending on the arguments:

  1. If you gave it a branch name: It switched branches.
  2. If you gave it a file name: It overwrote the file (discarding changes).

This was dangerous. A typo in a branch name could lead you to overwrite files unintentionally. That’s why, in Git 2.23, they decided to split this command into two more specific ones:

  • git switch: For switching branches (we’ll see this later).
  • git restore: For restoring files (what we’re seeing today).

git checkout still works for backward compatibility and isn’t going away anytime soon. But, for semantics and safety, **we strongly recommend you use git restore**.

Removing files from the Staging Area

This is the other main use of restore. Let’s assume the following case:

  1. You modify app.js (a good change).
  2. You modify claves.txt (a file with passwords that you do NOT want to upload).
  3. Out of habit, you type git add ..

Now you have claves.txt in the Staging Area. If you commit, you’re in trouble, because it would be recorded in Git’s history.

You need to remove it from the Stage, but without deleting the file from your disk (because you want your password file).

git restore --staged claves.txt
Copied!

By using the --staged flag, we are telling Git: “Restore the version of the file that is in the Stage to match the one from the last commit”.

The result is that the file is removed from the staging area and goes back to being simply Modified (or Untracked if it was new).

In the past, this was done with the cryptic git reset HEAD claves.txt. Now, with restore, it’s much more logical.

On this page