Back to Blog
Lesson 12 of the Git & GitHub: Git & GitHub from Zero course
GitJuly 30, 20264 min read

Unstaging Files: How to Use git restore --staged

Learn how to remove files from the staging area using git restore --staged. Safely undo your staging steps without losing your local file changes.

gitversion controlgit restorestagingcommand linedevops
Close-up of software development tools displaying code and version control systems on a computer monitor.

Previously in this course, we explored Undoing Uncommitted Changes with Git Restore to discard modifications in your working directory. This lesson focuses on the opposite problem: what happens when you've already moved files into the staging area but aren't ready to commit them.

When working with Git, it is easy to accidentally run git add . and include files you didn't intend to track, or perhaps you staged a file that isn't quite finished yet. Learning to "unstage" is a critical skill for maintaining clean, logical commit history.

Understanding the Staging Area

As we covered in Understanding the Git Lifecycle: Staging Area & Working Directory, the staging area acts as a "waiting room" for your next commit. When you use git add, you are telling Git, "Prepare these specific changes for the next snapshot."

Sometimes, you might add too many files or realize a specific file needs more work before it belongs in a commit. You don't want to delete the file from your computer; you simply want to remove it from the staging area so it stays in your working directory as an unstaged change.

Removing Files with git restore --staged

Close-up of software development tools displaying code and version control systems on a computer monitor.

The modern, safe way to remove files from the staging area is the git restore command with the --staged flag. This command tells Git to take the file out of the "waiting room" while keeping your local modifications exactly as they are.

Worked Example

Imagine you are working on our project and you accidentally add a temporary log file to the staging area.

  1. First, check your status to see the current state:

    Bash
    git status

    Output:

    TEXT
    Changes to be committed:
      modified:  project-notes.txt
      new file:  temp-log.txt
  2. You realize temp-log.txt should never be committed. Instead of panicking, you use the restore command:

    Bash
    git restore --staged temp-log.txt
  3. Run git status again to verify:

    TEXT
    Changes to be committed:
      modified:  project-notes.txt
    
    Untracked files:
      temp-log.txt

Notice that the file is no longer in the "Changes to be committed" section. It has been safely moved back to your working directory, where you can now Ignoring Files: Mastering .gitignore for Cleaner Repositories if you don't want to track it at all.

Hands-on Exercise

To practice this workflow:

  1. Create a new file named draft.txt and add some text to it.
  2. Run git add draft.txt to stage the file.
  3. Check git status to confirm it is staged.
  4. Run git restore --staged draft.txt to unstage it.
  5. Confirm the file still exists in your folder, but is no longer staged.

Common Pitfalls

  • Confusing restore with remove: Beginners often reach for git rm, which actually deletes the file from your disk. Remember: git restore --staged is for changing your mind about the commit, not for deleting your work.
  • Forgetting the flag: If you run git restore without --staged, Git will try to discard the changes inside your file, reverting it to the version in your last commit. Always include --staged if you only want to change the staging status.

FAQ

Q: Does unstaging files delete my code? A: No. git restore --staged only changes the status of the file in Git's index; it leaves your actual file contents untouched.

Q: Can I unstage multiple files at once? A: Yes. You can pass multiple filenames (e.g., git restore --staged file1.txt file2.txt) or use a directory path to unstage everything within that folder.

Q: Is there an older way to do this? A: You may see references to git reset HEAD <file>. This was the standard command before git restore was introduced in Git version 2.23. While it still works, git restore is preferred for its clarity and safety.

Recap

Team members presenting a project in a modern office setting with a focus on collaboration.

You now know how to recover from over-eager staging. By using git restore --staged, you maintain precise control over what enters your repository history, ensuring only intended changes are captured in your commits. This is a vital step in maintaining the "clean, atomic commits" that professional teams rely on.

Up next: Navigating Commits — viewing past states and moving through your project history.

Similar Posts