Introduction

Reviewing a diff before committing is one of the simplest ways to avoid noisy history and accidental mistakes. Git lets you compare the working tree, the staging area, and the last commit, so you can confirm exactly what will be recorded before you run git commit.

Understand Which Diff You Want

Most confusion comes from not knowing which two states Git is comparing. There are three common views:

• working tree versus staging area
• staging area versus last commit
• working tree versus last commit

The default git diff command shows unstaged changes. That means Git compares the current file on disk with the staged copy in the index.

git diff

If you want to limit the output to one file, pass the path:

git diff -- src/app.js

That is the fastest way to inspect a single file before deciding whether to stage it.

Review What Will Actually Be Committed

After you stage changes with git add, use git diff --cached to review the exact patch that will go into the next commit.

git add src/app.js
git diff --cached

Again, you can narrow the diff to one file:

git diff --cached -- src/app.js

This distinction matters because a file can have both staged and unstaged edits at the same time. If you only run git diff, you are not necessarily seeing what the next commit contains.

To compare your current working copy against the last commit in one shot, use:

git diff HEAD -- src/app.js

That view includes both staged and unstaged changes relative to HEAD.

Use Better Diff Views

Large patches are easier to understand with a few helpful options.

Word-level changes are useful for prose, configuration, or short line edits:

git diff --word-diff

If rename detection matters, especially during refactors, compare with status as well:

git status
git diff --cached --find-renames

For terminal review, it is also worth enabling a pager and color if your setup does not already do that:

git config --global core.pager less
git config --global color.ui auto

Those are not required, but they make repeated diff review much easier.

Stage Selectively Before Commit

One of the best habits is staging only the parts that belong in the commit you are about to write. Git supports this directly with patch mode:

git add -p src/app.js

Patch mode walks through each hunk and lets you decide whether to stage it. That is useful when one file contains both a bug fix and unrelated formatting changes. After staging only the relevant hunks, run git diff --cached and verify that the commit is focused.

A practical workflow looks like this:

1git status
2git diff -- src/app.js
3git add -p src/app.js
4git diff --cached -- src/app.js

That sequence catches most accidental commits before they happen.

Common Pitfalls

The most common mistake is reviewing only git diff and assuming that is the future commit. It only shows unstaged changes. If files are already staged, you also need git diff --cached.

Another issue is forgetting that generated files, lock files, or formatting-only edits may be mixed into the patch. git status is a good first checkpoint because it shows which files are modified, staged, or untracked before you inspect the patch itself.

Developers also sometimes commit from a dirty working tree without realizing one file contains extra debug logging. A focused pre-commit diff review is the cheapest defense against that kind of mistake.

Finally, very large diffs are hard to reason about. If review feels difficult, that is often a signal that the commit should be split into smaller pieces.

Summary

• 'git diff shows unstaged changes.'
• 'git diff --cached shows the staged patch that will be committed.'
• 'git diff HEAD -- path shows all current changes for a file relative to the last commit.'
• 'git add -p helps build cleaner, smaller commits by staging selected hunks.'
• Reviewing diffs before commit reduces accidental changes and improves commit quality.