git
version control
file changes
pre-commit
coding tips

How to see changes to a file before commit?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Before committing in Git, you usually want to answer one simple question: what exactly changed in this file? The correct command depends on which comparison you mean. Git can show differences between your working tree and the index, the index and the last commit, or the file in your current branch versus another commit or branch.

Understand the Three States Git Compares

A file in Git typically exists in three relevant places:

  • the last committed snapshot, usually HEAD
  • the staging area, also called the index
  • your working tree copy

That is why there is no single universal “show my changes” command. Git needs to know which two states you want to compare.

See Unstaged Changes in One File

If you edited a file but have not staged it yet, use git diff with the path.

bash
git diff -- src/app.js

This shows the difference between the working tree and the index for that file only. It is the most common answer when you want to inspect local edits before deciding whether to stage them.

If you omit the file path, Git shows unstaged changes for all modified files.

See Staged Changes That Will Go Into the Commit

Once you run git add, the working tree diff is no longer the whole story. To inspect what is currently staged for commit, use:

bash
git diff --staged -- src/app.js

Some older documentation uses --cached, which is equivalent:

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

This command is often more important than plain git diff, because the commit is built from the index, not directly from your working directory.

See Everything Different From the Last Commit

If you want the full delta between the file in your current work and the version in HEAD, compare against HEAD directly.

bash
git diff HEAD -- src/app.js

This includes both staged and unstaged changes. It is useful when you want one combined view of everything you have changed since the last commit.

A practical review sequence is:

bash
git diff -- src/app.js
git diff --staged -- src/app.js
git diff HEAD -- src/app.js

Together, those three commands tell you exactly what is unstaged, what is staged, and what changed overall.

Use Readable Output Options

Raw diffs are precise, but sometimes you want a quicker summary. Git provides a few helpful options.

Show only changed filenames and counts:

bash
git diff --stat HEAD -- src/app.js

Show word-level changes for prose or Markdown files:

bash
git diff --word-diff -- docs/article.md

Show color and context in a pager:

bash
git diff -- src/app.js | less -R

The right output format depends on the kind of file and how much context you need before committing.

Review Parts of a File Before Commit

Sometimes the problem is not whether the file changed, but whether all of its changes belong in one commit. In that case, review and stage selectively with patch mode.

bash
git add -p src/app.js

After interactively staging the relevant hunks, inspect the staged result:

bash
git diff --staged -- src/app.js

This workflow is cleaner than making one oversized commit and hoping to tidy history later.

Compare Against Another Branch or Commit

If you want to see how your version of a file differs from another branch, name both references explicitly.

bash
git diff main -- src/app.js
git diff HEAD~1 -- src/app.js

That is useful when preparing a pull request, checking whether a hotfix was already applied elsewhere, or confirming what changed since a known commit.

Common Pitfalls

A common mistake is using only git status. It tells you which files changed, but not what changed inside them.

Another issue is reviewing only git diff and forgetting git diff --staged. Once files are staged, the staged snapshot may differ from what is currently in the working tree.

Developers also sometimes forget the -- separator before the path. It is not always required, but it prevents ambiguity when a branch and a file share similar names.

Finally, do not assume the commit will include every visible working-tree change. Git commits the index, so always inspect the staged view before finalizing the commit.

Summary

  • Use git diff -- <file> to inspect unstaged changes.
  • Use git diff --staged -- <file> to inspect what is currently staged for commit.
  • Use git diff HEAD -- <file> to see all changes since the last commit.
  • Use git add -p when only part of a file belongs in the next commit.
  • Review the staged snapshot, not just the working tree, before committing.

Course illustration
Course illustration

All Rights Reserved.