If you staged a file in a Git project on your Mac but want to leave it out of the next commit, run git restore --staged for that file from Terminal. This updates Git’s staging area while leaving the file in your working folder, so its edits remain available to review or stage later. Check the file path and confirm the result with git status before committing.

What “unstage” changes

Git keeps the proposed next commit in its index, also called the staging area. A commit normally includes staged changes; edits you have not staged remain in your working tree. Removing a file from the index therefore changes what is prepared for the commit, without asking Git to rewrite the working copy. Git documents git restore --staged as restoring the index from HEAD by default. Git’s restore documentation

This is useful when you staged the wrong file, or decided that one file should stay out of a commit. The command is file-specific when you give it one path. Do not add --worktree: Git’s documentation says using both --staged and --worktree restores both locations, which is not the goal when you want to keep your edits.

Unstage one file from Terminal

Open Terminal on your Mac and change to the repository folder. Terminal’s default shell is zsh, though a managed Mac may use a different shell. Apple’s Terminal guide

Run git status first. Find the staged file under “Changes to be committed” and note its path relative to the repository root. If you see a different repository or the path is unclear, stop and check your location before changing anything.

For example, to unstage src/Feature.swift, run:

git restore --staged -- src/Feature.swift

The -- separates options from the path. It is helpful for names that might otherwise be read as options. Quote paths containing spaces so zsh passes the path as one argument:

git restore --staged -- "Documentation/Setup Notes.md"

Use the path as Git reports it, including capitalization and any directory names. If you are already inside a repository subdirectory, Git path handling can be less obvious; running the command from the repository root and using the full repository-relative path makes the target easier to verify.

Confirm the edits are still there

Run git status again. For a tracked, modified file, the staged change should disappear from “Changes to be committed” and appear under “Changes not staged for commit.” That means the working copy still differs from HEAD, but the index no longer contains that proposed change. Git describes status as showing changes between HEAD and the index, and between the index and working tree. Git’s add documentation

You can inspect the unstaged edits with:

git diff -- "src/Feature.swift"

That diff compares the working file with the index. Because the index now matches HEAD for that tracked file, it shows the retained edits you removed from staging. To prepare the file for a later commit, stage it again with git add -- "src/Feature.swift".

What to expect for new files and deletions

If the file is new and has never been committed, it has no version in HEAD. After git restore --staged -- path/to/new-file removes it from the index, the file should remain on disk as an untracked file. Check that it appears under “Untracked files” in git status; do not delete it if you want to keep it.

If you staged the deletion of a tracked file, restoring the index from HEAD puts the tracked version back in the index, while the working copy remains deleted. Status should show an unstaged deletion. This distinction matters: unstaging does not necessarily make the working tree look unchanged; it preserves the state currently present on disk.

If you staged only part of the file

The same command unstages the file’s staged contents as a whole. If you intentionally staged some hunks and want to keep only selected ones staged, do not run the whole-file command. Git’s restore command supports interactive patch mode, but selecting the right direction and hunks requires care. Review Git’s documented git restore --patch behavior before using it; Git also documents git add --patch for interactively choosing hunks to stage. Git’s restore documentation

Avoid git restore --worktree or git restore --staged --worktree for this task. Those options affect the working tree and can discard the very edits you are trying to keep. If the result in git status differs from what you expected, pause and inspect the path and diff before running another restore command.

Sources