Introduction

Git tags are usually used to mark releases or other important points in history. Comparing two tags is really just comparing the commits they point to, and Git gives you several ways to do that depending on whether you care about file content, commit history, or just a quick summary.

The Most Common Comparison Commands

If you want to see the code differences between two tags, use git diff:

git diff v1.2.0 v1.3.0
git diff --stat v1.2.0 v1.3.0
git diff --name-status v1.2.0 v1.3.0

Those commands answer slightly different questions:

• plain git diff shows the actual line-by-line patch
• '--stat shows file counts and insertion-deletion totals'
• '--name-status shows which files changed and whether they were added, modified, or deleted'

If you care about the commits that happened between the two releases, use git log instead:

git log --oneline --decorate v1.2.0..v1.3.0
git log --reverse --oneline v1.2.0..v1.3.0

The two-dot range means "commits reachable from v1.3.0 that are not reachable from v1.2.0". That is often exactly what you want for release notes.

Comparing One File or One Tag Object

Sometimes you do not want the whole release diff. You want to inspect a single file across tags.

git diff v1.2.0 v1.3.0 -- src/app.py
git show v1.2.0:src/app.py
git show v1.3.0:src/app.py

That is especially useful when one release contains a large amount of unrelated churn but you only care about one module.

Annotated tags and lightweight tags can both be compared this way because Git resolves both tags to commits before running the diff. The comparison behavior is about the target commits, not the tag metadata.

Make Sure the Tags Exist Locally

A surprising number of comparison problems come from stale local tags. If the repository was cloned without tags, or if newer release tags were created on the remote after your last fetch, update them first.

git fetch --tags
git tag --list

Once the tags are present locally, the comparison commands work exactly the same as branch or commit comparisons.

Choosing the Right View

Pick the command based on the question you are asking:

• use git diff when you want to review code changes
• use git log old..new when you want the commit list between releases
• use git diff --stat for a lightweight summary
• use git show tag:path when you want one file at one release point

If you need a merge-aware review, git range-diff can also be useful, but that is usually for comparing patch series rather than simple release tags.

Common Pitfalls

• Forgetting git fetch --tags and then comparing outdated local tag data.
• Reversing the tag order. git diff old new answers a different question from git diff new old because additions and deletions flip direction.
• Using git log tag1 tag2 when you actually wanted git log tag1..tag2.
• Assuming annotated tags compare differently from lightweight tags. In normal diff and log commands, both resolve to the commits they reference.
• Comparing tags in a shallow clone that does not contain enough history.

Summary

• Comparing two tags in Git usually means comparing the commits those tags point to.
• 'git diff tag1 tag2 shows code changes, while git log tag1..tag2 shows the commit history between them.'
• '--stat and --name-status are useful summary forms of the diff.'
• Fetch tags first if you are not sure the local repository is up to date.
• Use file-specific comparisons when the full release diff is too noisy.