How can I tell staged changes from unstaged changes in Git?

Use two diff views, because they compare different parts of your working state:

• Run git diff --cached to inspect staged changes. git diff --staged is an alternative spelling. This compares the index with HEAD and shows changes staged for the next commit. [S1]
• Run git diff to inspect unstaged edits. It compares the working tree with the index. [S1]

Read the staged view to review what is prepared for the commit, then read the plain view to see what remains unstaged. Don’t treat the plain git diff output as a complete preview of the commit: it shows the difference between your working tree and the index, not the staged comparison with HEAD.

The staged and unstaged views can show separate parts of the same file. The staged diff shows the index compared with HEAD; the unstaged diff shows the working tree compared with the index. [S1]

For example, suppose you stage a heading correction, then add a paragraph to that same file without staging the later edit. Use git diff --cached to review the heading change prepared for the commit, and git diff to review the paragraph edit that remains unstaged. This is an illustrative example, not output from a particular repository.

Review each view on its own. A file appearing in the staged view does not mean every current edit to that file is staged. Checking both helps distinguish what is prepared for the next commit from later edits. [S1]

Try this sequence:

1. Run git diff --cached and read the staged changes as the contents prepared for your next commit.
2. Run git diff and read the unstaged changes as edits outside the index.
3. If you see the same file in both views, inspect both outputs: they can represent different edits in that file.
4. If the staged view contains something you did not intend to include, pause and review it before committing. Don’t rely on the unstaged view to show what is staged.

The point is not that every unstaged edit must be included or discarded. The two views help you make that decision separately: first assess the proposed commit, then assess the edits that are still outside it. [S1]

If both comparisons show no changes, they show no differences at those two boundaries when you ran them. That does not, by itself, tell you whether an earlier commit was correct. The staged view is normally described as a comparison with HEAD, but Git documents an exception for staged-diff behavior on an unborn branch. [S1]

For a straightforward pre-commit check, remember the distinction: git diff --cached (or git diff --staged) is for changes staged for the next commit; git diff is for working-tree edits not staged in the index. Review both when you need to separate the two. [S1]