Why git diff is empty after git add

You edited a file, staged it, and ran git diff. Nothing appeared. Before trying an undo command, check the comparison: plain git diff compares the working file with the index. After staging all its changes, those two copies can match.

The change can still be staged for your next commit. Use git diff --cached to inspect that comparison. The official git diff reference describes the different forms.

Three versions of one file

For an ordinary tracked file in a repository with an existing commit, keep these three versions in mind:

• HEAD: the version in the current commit.
• The index: the version prepared for the next commit.
• The working file: the saved contents on disk.

Run this inspection sequence from the repository root:

git status --short
git diff -- app.txt
git diff --cached -- app.txt
git diff HEAD -- app.txt

The commands answer, respectively: what is the path's status, what differs between disk and index, what differs between index and HEAD, and what differs between disk and HEAD. They inspect content without editing it.

A small example you can follow

Use a practice repository where app.txt was committed with one line, color=blue. In your editor, change that line to color=green and save it. Plain git diff should show the color change; the cached comparison should be empty if nothing else was staged for this file.

Now stage that path:

git add -- app.txt
git diff -- app.txt
git diff --cached -- app.txt

Plain diff is now empty, but the cached diff still shows the color change. Staging copied the saved contents into the index; it did not create a commit. The git add documentation explains how staging records file contents.

What if you edit the file again?

After staging the green version, add a second line, theme=dark, and save without staging again. The plain diff now shows the extra theme line. The cached diff still shows the earlier color change, and a comparison with HEAD shows both saved changes.

Short status can show MM for this case. In the ordinary tracked-file case, its first column describes the index and its second describes the working tree. A staged-only modification has M in the first column; an unstaged-only modification has M in the second. See the git status reference for other states, including conflicts.

New and ignored files need another check

git status --short --untracked-files=all
git status --short --ignored -- build.log

An untracked file can contain useful work even when plain diff shows nothing; short status marks it with two question marks. An ignored path can appear with two exclamation marks when ignored files are requested. Open the relevant file and check its tracking state before deciding what to stage.

Review the proposed commit

Before committing, read git diff --cached without a path filter to review everything currently staged. If a tracked file belongs in a later commit, the unstaging tutorial shows how to remove it from that selection while preserving its current saved contents.