GIT: Revert uncommitted changes in tracked files

24.1. Use cases

If you have a tracked file in Git, you can always recreate the file content based on the staging area or based on a previous commit. You can also remove staged changes from the staging area to avoid that these changes are included in the next commit. This chapter explain you how you can do this.

24.2. Remove staged changes from the staging area

Staging area, remove staged changes You can use the git reset [paths] command to remove staged changes from the staging area. This means that git reset [paths] is the opposite of git add [paths]. It avoids that the changes are included in the next commit. The changes are still available in the working tree, e.g., you will not lose your changes and can stage and commit them at a later point.

In the following example you create a new file and change an existing file. Both changes are staged.

# do changes
touch unwantedstaged.txt
echo "more.." >> test02

// add changes to staging area
git add unwantedstaged.txt
git add test02

# see the status
git status

The output of git status command should look similar to the following.

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   test02
    new file:   unwantedstaged.txt

Remove the changes from the staging area with the following command.

# remove test02 from the staging area
git reset test02

# remove unwantedstaged.txt from the staging area
git reset unwantedstaged.txt

Use the git status command to see the result.

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   test02

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    unwantedstaged.txt

no changes added to commit (use "git add" and/or "git commit -a")

The git reset behaves differently depending on the options you provide. To learn more about the git resetcommand.

24.3. Remove changes in the working tree

Be careful with the following command. It allows you to override the changes in files in your working tree. You will not be able to restore these changes.

Changes in the working tree which are not staged can be undone with git checkout command. This command resets the file in the working tree to the latest staged version. If there are no staged changes, the latest committed version is used for the restore operation.

# delete a file
rm test01

# revert the deletion
git checkout -- test01

# note git checkout test01 also works but using
# two - ensures that Git understands that test01
# is a path and not a parameter

# change a file
echo "override" > test01

# restore the file
git checkout -- test01

For example, you can restore the content of a directory called data with the following command.

git checkout -- data

24.4. Remove changes in the working tree and the staging area

If you want to undo a staged but uncommitted change, you use the git checkout [commit-pointer] [paths]command. This version of the command resets the working tree and the staged area.

The following demonstrates the usage of this to restore a delete directory.

# create a demo directory
mkdir checkoutheaddemo
touch checkoutheaddemo/myfile
git add .
git commit -m "Adds new directory"

# now delete the directory and add the change to
# the staging area
rm -rf checkoutheaddemo
# Use git add . -A for Git version < 2.0
git add .

# restore the working tree and reset the staging area
git checkout HEAD -- your_dir_to_restore

The additional commit pointer parameter instructs the git checkout command to reset the working tree and to also remove the staged changes.

24.5. Remove staging area based on last commit change

When you have added the changes of a file to the staging area, you can also revert the changes in the staging area base on the last commit.

# some nonsense change
echo "change which should be removed later" > test01

# add the file to the staging area
git add test01

# restores the file based on HEAD in the staging area
git reset HEAD test01