Introduction

If you want to compare two specific Git commits, you do not need to replay or inspect the commits that happened between them. Git can diff the two snapshots directly. The important part is choosing the right diff syntax, because some forms compare exact endpoints while others compare against a merge base.

Compare two exact snapshots with git diff

The basic command is:

git diff <older-commit> <newer-commit>

For example:

git diff a1b2c3d 9f8e7d6

This shows the file changes needed to go from commit a1b2c3d to commit 9f8e7d6. It does not matter how many commits exist between them. Git compares the content trees of the two endpoints.

You can also use branch names, tags, or HEAD:

git diff release-1.0 release-1.1
git diff HEAD~10 HEAD

That is the standard answer when the question is "show me the difference between these two states of the repository."

Useful views of the same comparison

Depending on what you need, there are several flags that keep the same endpoint comparison but change the presentation.

Show only changed file names:

git diff --name-only a1b2c3d 9f8e7d6

Show a summary of insertions and deletions:

git diff --stat a1b2c3d 9f8e7d6

Show changes for one file only:

git diff a1b2c3d 9f8e7d6 -- src/app.py

These options are useful when the full patch is too noisy and you need a faster overview first.

If the diff is mostly textual edits and you want a more readable inline view, --word-diff can also help:

git diff --word-diff a1b2c3d 9f8e7d6

That keeps the same endpoint comparison while presenting changes at a word granularity instead of only full lines.

Do not confuse exact diffs with triple-dot diffs

A common point of confusion is the difference between:

• 'git diff A B'
• 'git diff A...B'

git diff A B compares the exact snapshots A and B.

git diff A...B compares the merge base of A and B to B. That is often useful in pull request reviews because it focuses on changes introduced on one side of a branch, but it is not the same as comparing the two commits directly.

If your requirement is "ignore intervening commits and just compare these two commits," use the two-endpoint form.

Inspect commit history separately if needed

Sometimes people really want two different things:

• the content difference between two commits
• the list of commits that happened between them

Those are separate commands.

To list the commits between two points:

git log --oneline a1b2c3d..9f8e7d6

To see the combined content difference:

git diff a1b2c3d 9f8e7d6

Using both together is often the most informative workflow during debugging or release reviews.

Compare changes in a GUI or external diff tool

If the patch is large, you can still use the same commit range with a visual tool:

git difftool a1b2c3d 9f8e7d6

This launches your configured diff viewer file by file. The underlying comparison is the same; only the presentation changes.

Common Pitfalls

The most common mistake is assuming A..B in git diff means "all changes between A and B." In practice, git diff A B already compares the two snapshots you care about. Double-dot and triple-dot syntax matter more in git log than they do in basic endpoint comparison.

Another issue is using git diff A...B by habit and then wondering why some changes seem missing. That command uses the merge base, so it intentionally answers a different question.

It is also easy to forget file path filtering. If you only care about one directory, add -- path/to/dir to reduce noise.

Finally, remember that commit order affects the patch direction. Swapping the two commits changes additions into deletions and vice versa, even though the endpoint pair is the same.

Summary

• Use git diff <commit1> <commit2> to compare two exact commits directly.
• Add flags such as --stat or --name-only when you want a summary first.
• Use git log <commit1>..<commit2> separately if you also want the list of commits in between.
• Avoid git diff A...B unless you specifically want a merge-base comparison.
• Keep the commit order straight because it affects the direction of the diff.