Use Git Diff to See Exactly What Changed Before Committing

Committing code without checking it first is like sending an email without reading it. You might include a debug line, a wrong file, or a half-finished idea. Many Git mistakes happen simply because the developer never looked at the changes before pressing commit.

The command that solves this is git diff. It shows you exactly what changed in your files, line by line, before anything is saved into history. Learning to read it well will make your commits cleaner and your code reviews much easier.

In this guide, you will learn the different forms of git diff, how to read its output, and how to build a simple checking routine before every commit.

Quick Answer

Run git diff to see unstaged changes in your working files, and run git diff --staged to see changes you have already added and are about to commit. Lines starting with a minus sign in red were removed, and lines starting with a plus sign in green were added. Review both outputs before you run git commit.

Why Checking Changes Before Committing Matters

A commit is a permanent snapshot in your project history. Teammates will read it, reviewers will judge it, and future developers may use it to understand why code was written. A messy commit makes all of that harder.

Using git diff helps you catch small errors early. You may spot a forgotten console log, a commented-out block you meant to delete, or a password you pasted for testing. Catching these before commit is far easier than fixing history after you push.

Diff also helps you write better commit messages. When you see the full set of changes in front of you, you can describe them accurately. If the diff shows two unrelated topics, that is a sign you should split the work into two smaller commits.

Understanding the Three Places Git Stores Changes

To use git diff correctly, you need to understand where your changes live. Git works with three main areas.

• Working directory: The real files on your computer that you edit in your editor.
• Staging area: A waiting area for changes you have marked with git add and plan to commit next.
• Repository: The committed history created when you run git commit.

Each form of git diff compares two of these areas. Once you know which comparison you are making, the output stops being confusing and starts being very precise.

If this model is new to you, our overview on how Git and GitHub work for complete beginners explains the working directory, staging, and commits with simple diagrams and examples.

The Main git diff Commands You Need

1. See Unstaged Changes

Run git diff with no extra options. This compares your working directory with the staging area. In simple words, it shows changes you have made but not yet added with git add.

2. See Staged Changes Ready to Commit

Run git diff --staged. You can also use git diff --cached, which means the same thing. This compares the staging area with the last commit. It shows exactly what will go into your next commit if you run git commit now.

This is the most important final check. Many developers run the first command often but forget this one. If you only have time for one check before committing, make it this one.

3. See All Changes Together

Run git diff HEAD to compare your working directory directly with the last commit. This shows staged and unstaged changes together in one view. It is useful when you want a complete picture before you decide how to organize your commits.

The official Git diff command documentation lists every option, including comparisons between branches and commits, but these three forms cover almost all daily work.

How to Read git diff Output

At first, diff output looks technical, but it follows a simple pattern. Let us break it into parts.

1. The header shows the file name, with a/ for the older version and b/ for the newer version.
2. A line starting with @@ shows where the change is in the file and how many lines are involved. This is called a hunk.
3. Lines starting with a minus sign - were removed. In a terminal with color, they appear in red.
4. Lines starting with a plus sign + were added. They appear in green.
5. Lines starting with a space did not change. Git shows them only to give you context around the change.

Read a diff from top to bottom, file by file. For each hunk, ask yourself two questions. Did I mean to remove this? Did I mean to add this? If the answer to either question is no or not sure, stop and open the full file before you commit.

Useful Options to Make diff Easier

See a Short Summary Instead of Full Lines

Sometimes you only want to know which files changed and how much. Run git diff --stat for a summary with insertions and deletions per file. For staged changes, run git diff --staged --stat. This is perfect for a quick check on a large project.

Check Only One File

Run git diff -- filename.txt or git diff --staged -- src/app.js to limit the output to a single file or folder. This keeps your review focused and prevents endless scrolling when many files changed.

Ignore Whitespace-Only Changes

If your editor changed spaces or line endings, the diff can look huge even though the code did not really change. Run git diff -w to ignore whitespace changes and see the real logic changes. Use this for reading, but still fix formatting problems properly in your project.

See Word-Level Changes

For text files like documentation, a whole line may change because of one word. Run git diff --word-diff to highlight changed words inside the line instead of showing the full line as removed and added. Writers find this option especially helpful.

You can explore more display options in the official Git diff options reference, which explains stat, color, and context settings in detail.

A Simple Routine Before Every Commit

1. Run git status to list changed and untracked files. Make sure no unexpected file appears.
2. Run git diff to review unstaged changes while you edit.
3. Add the files you want with git add, choosing specific files when you need separate commits.
4. Run git diff --staged as your final review. Read every hunk once.
5. If the diff mixes two topics, unstage one part with git restore --staged filename and commit the topics separately.
6. Write a commit message that matches what the staged diff actually shows.

This routine takes one or two minutes, even on a medium change. In return, it prevents most embarrassing commits and makes your project history easy to follow months later.

Common Mistakes to Avoid

• Only running git status and never git diff: Status tells you which files changed, but not what changed inside them. Always read the actual lines.
• Forgetting –staged before commit: Plain git diff does not show staged changes. If you added files early, you may commit without ever reviewing them.
• Committing a giant diff in one go: A huge diff usually means the commit is too big. Split it into smaller, clear commits that are easier to review and undo.
• Ignoring new untracked files: Plain diff does not show untracked files at all because Git is not tracking them yet. Check git status for them separately.
• Skipping the diff because tests passed: Passing tests do not prove you avoided committing debug code, local paths, or secrets. Only reading the diff proves that.
• Getting lost in the pager: If the output feels overwhelming, limit it by file, use --stat first, and review one file at a time instead of giving up.

Conclusion

git diff is your safety check before every commit. Use plain git diff to see work you have not staged, git diff --staged to see exactly what you are about to commit, and git diff HEAD when you want the full picture.

Build the habit now while your projects are small. Read the red and green lines, question anything you do not recognize, and split mixed changes into clear commits. Your future self, your reviewers, and your teammates will all thank you for a history that is easy to trust and easy to understand.

Frequently Asked Questions

Why does git diff show nothing even though I changed a file?

The most common reason is that you already staged the change with git add. Plain git diff only shows unstaged changes. Run git diff --staged to see the staged version, or check git status to confirm the file state.

What is the difference between git diff and git diff –staged?

git diff compares your working files with the staging area, so it shows changes not yet added. git diff --staged compares the staging area with the last commit, so it shows exactly what your next commit will contain.

How do I exit the git diff screen in the terminal?

Press the q key. The diff opens in a pager program, and q stands for quit. Use the arrow keys or Page Up and Page Down to scroll before you exit.

Can git diff show changes in a new untracked file?

No. Git does not track the file yet, so there is nothing to compare. Run git add on the file first, then git diff --staged will show its full content as added lines.

How can I see a summary without all the lines?

Run git diff --stat for unstaged changes or git diff --staged --stat for staged changes. You will get each file name with a count of added and removed lines, which is ideal for a quick overview.