What "git add" does and how to reverse it
When you run git add, you are telling Git to stage files — to mark them as ready to be included in your next commit. Staging is a separate step from committing, which means you can add files, change your mind, and remove them from the staging area before you actually save them to your repository history.
Undoing a git add is straightforward: you use the command git reset to move files back out of the staging area and into your working directory. The files themselves are not deleted or changed — they simply go back to being untracked or modified files that Git is no longer preparing to commit.
The key thing to understand is that undoing an add happens before you commit. Once you commit, the files are saved to your repository history, and you need a different approach to undo them. This guide covers how to reverse an add that you have not yet committed.
Key Takeaways
- Use git reset HEAD filename to unstage a single file you added by mistake.
- Use git reset HEAD with no filename to unstage all files at once.
- The files remain in your working directory unchanged — they are only removed from the staging area.
- If you have already committed the files, you need git revert or git reset with a commit hash, not just git reset HEAD.
Unstaging a single file
If you added one file by mistake and want to remove it from the staging area, use this command:
git reset HEAD filename
Replace filename with the actual name of the file. For example, if you accidentally added a file called config.txt, you would type:
git reset HEAD config.txt
Git will respond by showing you that the file has been unstaged. The file still exists in your working directory with all your changes intact — it is just no longer marked for commit. You can now edit it further, delete it, or leave it alone without affecting your next commit.
Unstaging all files at once
If you ran git add . or git add * and staged everything, but now want to start over, use:
git reset HEAD
This command unstages every file you added. Git will list each file as it removes it from the staging area. All your changes are preserved in your working directory — nothing is deleted or lost.
After running this command, you can then selectively add back only the files you actually want to commit, or you can review what you have changed before deciding what to stage.
Unstaging files that match a pattern
Sometimes you want to unstage only certain files — for example, all .log files or all files in a specific folder. You can do this by adding a pattern to the reset command:
git reset HEAD *.log
This unstages all files ending in .log. You can also unstage all files in a folder:
git reset HEAD folder/
Replace folder with the actual folder name. This removes all files in that folder from the staging area while leaving files in other folders staged.
Checking what you have staged before undoing
Before you unstage files, it is helpful to see exactly what you have added. Use:
git status
This shows you two lists: files in the staging area (under "Changes to be committed") and files in your working directory that have not been staged yet (under "Changes not staged for commit"). This helps you confirm which files you want to unstage.
You can also use git diff --staged to see the actual changes in the files you have staged. This is useful if you want to review what you added before deciding whether to unstage it.
What happens to your files after you unstage them
Unstaging a file does not change the file itself. If you added a file with new content, that content is still there — it is just no longer marked for commit. If you added a file with changes to existing content, those changes remain in the file.
The only thing that changes is Git's staging status. The file moves from "staged" to "unstaged" or "untracked", depending on whether it is a new file or a modified existing file. You can see this change by running git status again.
Undoing an add after you have already committed
If you committed files and now realize you should not have, git reset HEAD will not help — those files are already saved in your repository history. Instead, you have two options.
The first option is git revert, which creates a new commit that undoes the changes from a previous commit. This is the safest approach if other people are using your repository, because it does not erase history.
The second option is git reset with a commit hash, which moves your repository back to an earlier state. This erases the commits you want to undo, so use it only if you are working alone or if your team agrees to it. Both approaches require identifying the commit hash, which you can find with git log.
Frequently Asked Questions
Does git reset delete my files?
No. git reset HEAD only removes files from the staging area. Your files remain in your working directory with all changes intact. You can still edit them, commit them later, or delete them manually if you want.
What is the difference between git reset and git checkout?
git reset unstages files but leaves them changed in your working directory. git checkout discards changes to a file entirely and restores it to the last committed version. Use reset to unstage; use checkout only if you want to throw away your changes.
Can I undo a git reset if I change my mind?
Yes. Git keeps a log of all your actions in the reflog. Run git reflog to see your history, find the state you want to return to, and use git reset HEAD@{number} to go back. This works as long as you have not garbage-collected your repository.
What does HEAD mean in git reset HEAD?
HEAD is a pointer to your current branch's latest commit. git reset HEAD unstages files relative to that commit. You do not need to understand the technical details — just know that git reset HEAD filename is the standard command to unstage.
Can I unstage files from a specific commit in the past?
No. Unstaging only works on files you have added but not yet committed. If the files are already in a commit, you need git revert or git reset with a commit hash to undo them. Unstaging is only for the staging area, not for repository history.