Introduction

To diff one file against an arbitrary Git version, use git diff with a revision and a path. The important detail is the -- separator, which tells Git that the next token is a file path and not another revision name.

Compare the working tree to a historical commit

If your current copy of a file is on disk and you want to compare it with an older revision, the command is:

git diff HEAD~3 -- src/app.js

That means "show the difference between my current src/app.js and the version from three commits ago." You can replace HEAD~3 with a commit hash, branch name, or tag.

This form is useful when you are editing locally and want to see how far you have drifted from a known point in history.

Compare two committed versions of the same path

If the working tree is not part of the question, specify both revisions:

git diff main feature-branch -- src/app.js

This compares the file as it exists in main with the file as it exists in feature-branch. It is the right form when you care about repository history, not uncommitted changes.

You can also compare two specific commits:

git diff 4f21a6c 9d17f38 -- src/app.js

Compare different historical paths when a file moved

Renames complicate file diffing because the path may not be the same in both revisions. In that case, diff the file objects directly by using the rev:path syntax on both sides.

git diff HEAD~5:old/path/app.js HEAD:new/path/app.js

That tells Git exactly which historical blob to compare, even if the file was moved or renamed. It is often the cleanest answer when path history is not stable.

Use git show when you want raw file contents

Sometimes you do not want a diff yet. You want to inspect one exact version of the file:

git show HEAD~3:src/app.js

That prints the file content from that revision. It is useful for quick inspection or for piping into an external diff tool.

For example:

git show HEAD~3:src/app.js > /tmp/old-app.js
diff -u /tmp/old-app.js src/app.js

Use history commands when the path is unclear

If you are not sure when a file moved or what its older path was, inspect the log first:

git log --follow -- src/app.js

That helps you identify the right revision or former path before constructing the diff command. Without that step, you may ask Git to compare a path that did not exist in one of the revisions and get misleading results.

Remember the -- separator

The separator matters because Git parses both revisions and paths in the same command line grammar. This is correct and safe:

git diff HEAD -- README.md

If you skip --, Git may misread the file name as a revision in edge cases. That is especially annoying when branch names and file names overlap.

Common Pitfalls

• Forgetting the -- separator and confusing Git about whether a token is a revision or a path.
• Using git diff without a path and getting changes for the whole repository instead of one file.
• Comparing the working tree when the real question was about two committed revisions.
• Assuming git show produces a diff when it actually prints one file version.
• Using the wrong path for an older revision after the file has been renamed or moved.

Summary

• Use git diff <revision> -- <path> when comparing your current file with a historical version.
• Use git diff <revision1> <revision2> -- <path> for history-versus-history comparisons.
• Use git diff rev1:path rev2:path when the file moved and the path changed across history.
• Use git show <revision>:<path> when you need the raw contents of one version.
• Use git log --follow -- <path> first if a rename makes the correct historical path unclear.