Introduction

When you want to understand a commit, the main question is not just "what is the message" but "what changed compared with its parent." Git answers that in several ways, from a full patch view to compact summaries that are easier to scan during review.

Start with git show

The most direct command is git show. Given a commit hash, it prints the commit metadata and the patch introduced by that commit.

git show 8f3c2ab

That output usually includes:

• author and date
• commit message
• unified diff showing added and removed lines

For everyday debugging, this is often enough. If a test started failing after a specific change, git show tells you exactly which files and lines were touched.

You can also use symbolic references:

git show HEAD~1
git show main~3

Those forms are useful when you know the commit’s position relative to a branch tip but do not want to paste a full hash.

Use summaries when the full patch is too noisy

Sometimes you only need a quick overview before deciding whether to inspect the patch. Git can summarize the same commit in different levels of detail.

git show --stat 8f3c2ab

--stat shows which files changed and how many lines were added or deleted per file.

git show --name-only --format=fuller 8f3c2ab

--name-only lists file paths without the full diff, which is useful if you only want to know the scope of the change. The --format=fuller option adds more metadata such as author and committer timestamps.

If you want only the patch and not the commit header, use:

git show --format= 8f3c2ab

That is handy when you are pasting the diff into another tool or comparing it with another change.

Compare a commit against its parent explicitly

Under the hood, a normal commit is just the difference between that commit and its parent. You can express that with git diff.

git diff 8f3c2ab^ 8f3c2ab

This gives essentially the same patch as git show, but git diff becomes more flexible when you want to compare multiple commits, branches, or paths.

For example, to see only changes to one file in that commit:

git diff 8f3c2ab^ 8f3c2ab -- src/app.py

That is especially helpful in large commits where only one area matters to the bug you are tracking.

Inspect merge commits carefully

Merge commits need extra attention because they have more than one parent. A plain git show can be harder to interpret if you do not know which side of the merge you care about.

To see the parents:

git log --format=raw -n 1 3e4f9d1

To compare the merge commit against its first parent:

git diff 3e4f9d1^1 3e4f9d1

To compare it against the second parent:

git diff 3e4f9d1^2 3e4f9d1

This makes it easier to answer whether the merge introduced conflict-resolution edits or simply brought another branch in unchanged.

Use log views for broader context

A single commit often makes more sense when you also see nearby history.

git log --oneline --decorate -n 10

Then, once you spot the commit, inspect it in detail:

git log -p -n 1 8f3c2ab

The -p flag tells git log to include the patch. This is convenient when browsing history sequentially rather than jumping directly to one commit.

Another useful view is:

git blame src/app.py

git blame does not show what a commit did globally, but it does tell you which commit last changed each line in a specific file. That is often the fastest route from a suspicious line to the commit you need to inspect.

Common Pitfalls

The most common mistake is relying only on the commit message. Messages can be vague, outdated, or simply too short to explain the real behavioral impact. Always look at the diff before drawing conclusions.

Another issue is forgetting that merge commits have multiple parents. If you inspect a merge without checking which parent you are comparing against, the patch can look confusing or misleading.

Large refactors also create noise. In those cases, start with --stat or --name-only, then narrow the inspection to a specific file or path. Reading a huge patch all at once is usually slower than slicing it down to the relevant area.

Finally, remember that git show answers what changed in the repository, not necessarily what changed in runtime behavior. Build scripts, generated files, configuration, and test data can all influence impact differently, so pair the diff with domain context.

Summary

• 'git show <commit> is the fastest way to see what a commit changed.'
• Use --stat or --name-only when you want a compact overview first.
• 'git diff <commit>^ <commit> is useful when you want explicit parent-to-commit comparison.'
• For merge commits, compare against the correct parent with ^1 or ^2.
• Combine patch inspection with git log or git blame when you need surrounding context.