Introduction

Before committing, you usually want to answer one precise question: what changed in this file compared with the last commit or compared with what is staged. Git gives you direct commands for each comparison, and using the right one avoids committing accidental edits. The key is to distinguish between unstaged changes, staged changes, and the full difference from HEAD.

See Unstaged Changes in One File

If you modified a file but have not staged it yet, compare the working tree against the index:

git diff -- path/to/file

That shows only the unstaged edits for that path.

Example:

git diff -- src/app/service.py

This is usually the first command to run while reviewing an edit before staging it.

See Staged Changes in One File

If the file is already staged, compare the index against the last commit:

git diff --cached -- path/to/file

Example:

git diff --cached -- src/app/service.py

This answers the more important pre-commit question: what is actually going into the next commit.

See All Changes in the File Relative to HEAD

Sometimes you want both staged and unstaged changes together. Compare the file directly against the last commit:

git diff HEAD -- path/to/file

That shows the total difference between the working tree and the committed version, regardless of staging state.

This is helpful when you have partially staged the file and want a single combined review.

Use a More Readable Summary

If full patch output is too noisy, a summary view can be enough.

git diff --stat -- path/to/file

Or for staged changes:

git diff --cached --stat -- path/to/file

This is useful when you want a quick sense of how large the change is before opening the full diff.

Review Changes Interactively

If a file contains both intended and unintended edits, interactive staging helps isolate what should be committed.

git add -p path/to/file

After that, review the staged result:

git diff --cached -- path/to/file

This workflow is often better than trying to read one huge diff and mentally separate commit-worthy hunks from experimental ones.

Use git difftool If You Prefer a Visual Diff

If plain terminal patches are hard to scan, Git can launch a visual diff tool.

git difftool -- path/to/file

For staged changes:

git difftool --cached -- path/to/file

This depends on your Git difftool configuration, but it can be more comfortable for large refactors.

Check File Status Alongside the Diff

A diff tells you content changes. git status tells you whether the file is staged, unstaged, renamed, or untracked.

git status --short -- path/to/file

For example:

• 'M in the right column means unstaged modifications'
• 'M in the left column means staged modifications'
• both columns set means the file has both staged and unstaged changes

Reading diff output without checking status can be misleading when the file is partially staged.

A Practical Pre-Commit Workflow

A clean review sequence for one file is:

1. check status
2. inspect unstaged changes
3. stage intentionally
4. inspect staged changes

Example:

1git status --short -- src/app/service.py
2git diff -- src/app/service.py
3git add src/app/service.py
4git diff --cached -- src/app/service.py

This reduces the risk of surprise commits.

Common Pitfalls

The biggest mistake is using git diff after staging and assuming it shows what will be committed. Plain git diff shows unstaged changes, not the staged snapshot.

Another issue is forgetting the -- path separator, especially when a file path could be confused with a branch or revision name.

Developers also sometimes review only the total git diff HEAD -- file and miss the fact that only part of that change is actually staged.

Summary

• Use git diff -- path/to/file for unstaged changes.
• Use git diff --cached -- path/to/file for what is staged to commit.
• Use git diff HEAD -- path/to/file for the total change relative to the last commit.
• Combine git status --short with diff commands so you understand the file state.
• Use patch staging or a visual difftool when one file contains mixed-intent edits.