In this article, we’re going to look at two easy ways to remove files from the staging index in Git. In Git, there are many different commands that can be employed to accomplish the same goal. Below you’ll learn two commands that you can use to remove files and modifications from the staging index and what the differences are between them.
No matter what kind of work you’re doing, resetting, removing, or otherwise erasing files is dangerous. There’s always a possibility of losing work.
git rm <file> --cached method
This command will not remove files from the working directory, but only remove modifications and new files from the staging index.
git rm command can easily be confused with the
rm command available in most UNIX-like operating systems—including GNU/Linux operating systems and Mac OS.
/bin/rm) command and
git rm command function very differently. While
rm should be employed when removing files from your working directory, effectively erasing a file from existence,
git rm will remove files or file modifications from the Git staging index.
(Refresher: before files and file modifications are committed to your Git repository, they stop off in the staging index. Files, and any modifications to files, being tracked by your Git repository must be “staged” before they are committed. Only what is staged ends up in a commit.)
Thus, this is how are two commands are used separately:
rm> remove files from the working directory
git rm> remove content only from the Git staging index
To remove a file from the staging index, run the command like this:
git rm <file> --cached
No changes are made to the working directory.
git reset HEAD <file> method
git reset command is incredibly power and can wipe out your work entirely. So be careful to use this command with great caution.
git reset command is used to reset your project, or aspects of your project, to a certain state.
According to the Git documentation, you can think about
git reset as the opposite of
git add. This can be a helpful comparison. With
git add, you are adding changes into your list of staged changed (the staging index) that will eventually be rounded up and saved in a commit (with
git commit). The
git reset command does the opposite: it is basically hitting rewind on your project and restoring a former state.
As you can imagine, the process can be very helpful or massively destructive.
But in this instance, we’re safely going to use this command to remove items from the staging index, which can include:
- Modification made to tracked files
- New files added to the staging index as is
Here’s how the command is used. (In order to see the difference, run
git status before and after running the following command.)
git reset HEAD <file>
If you run
git status after this command, you’ll notice that modifications and new files added to the staging index have been removed yet no changes are made to the working directory.
Background Information on The Staging Index
The staging index is one of three important concepts about the architecture of Git and how it works.
In every project you’ll have working files. Once you’ve initiated a Git repository with
git init, you have your working files, a staging index (basically a list of changes that will be committed to the repository), and the repository.
So that is listed as follows:
- The working directory: the actual working files and directories associated with your project
- The staging index: a list of changes that will be committed
- The repository: the entire history of the project
Files in your project have four different statuses:
- Untracked (exists within the working directory but not “staged” for commits)
- Unmodified (Git is aware of the file, but no changes have been made, so there is nothing to commit)
- Modified (Changes have been made to the file, but not staged for commit)
- Staged (Changes have been successfully staged and will appear in next commit)
Well done! Now you know how you can remove files from your Git staging index. Be sure to leave a comment below or ask a question if you get stuck.