Why git status shows a file as both staged and modified

A file can appear under both “Changes to be committed” and “Changes not staged for commit” when you stage one version, then edit it again. Git keeps the staged snapshot in its index. Your later edits remain in the working copy until you stage them too.

Start with these commands, replacing notes.txt with your file:

git status --short
git diff --cached -- notes.txt
git diff -- notes.txt

The second command shows what the next ordinary commit would include for that path. The third shows edits made after its staged snapshot. Neither command changes your file.

Read the two status columns

For an ordinary tracked file outside a merge conflict, short status has two columns before the filename. The first compares the index with the current commit. The second compares your working copy with the index. See the official status output reference for the complete table, including conflict codes.

MM notes.txt

The first M means a modification is staged. The second means the working file also differs from that staged version. It is one path with two comparisons, not two copies competing to be committed. A space in either column matters:

• M : a modification is staged, with no further working-copy difference for that file.
• M: the tracked file has an unstaged modification.
• MM: it has both.
• AM: a newly added file was staged and then modified again.

See exactly which version Git staged

Consider a committed file containing two lines:

title=old
body=old

You change the first line to title=new, run git add -- notes.txt, then change the second line to body=new. The index still has the new title with the old body. The working copy has both changes.

git show :notes.txt
git diff --cached -- notes.txt
git diff -- notes.txt
git diff HEAD -- notes.txt

In this example, the cached diff contains the title edit; the ordinary diff contains the body edit. The HEAD comparison shows the combined working-copy changes relative to the current commit. These comparison modes are documented in git diff. An ordinary git commit uses the index; do not assume everything currently visible in your editor is staged.

Choose what belongs in the next commit

If the staged version is intentional, leave it staged. Review the cached diff before committing. This is useful when a later edit belongs in a separate change.

If you want the current whole file staged, run:

git add -- notes.txt
git diff --cached -- notes.txt
git status --short

That updates the staged snapshot. If you only want selected later changes, inspect them with git add -p -- notes.txt instead of staging the whole path.

If you want none of this file staged, use Git 2.23 or newer:

git restore --staged -- notes.txt
git status --short
git diff -- notes.txt

With an existing HEAD commit, this restores the index entry from HEAD and leaves the working file alone. Keep --staged: a working-tree restore has a different purpose and can discard edits. The restore reference explains the destination and default source.

What was checked

An isolated Git 2.55.0 Windows fixture verified the MM example, the separate patches, the staged snapshot, restaging, and byte-for-byte preservation after unstaging. It also verified that unstaging a newly added file changes AM to an untracked entry while retaining its contents. These examples assume a repository with an existing commit and no unresolved merge conflict.

For the next step, use the full unstaging walkthrough. If the ordinary diff is unexpectedly empty after staging, see why git diff is empty after git add.