git show

What you will learn

• Understand the core purpose of git show
• Master the basic usage and common options of git show
• Inspect a specific commit, tag, or object in detail, making it one of the most useful commands for reading history precisely.
• Understand key concepts: Common uses
• Know when to use this feature and when to avoid it

git show expands a single object into readable detail. Most often that means commit metadata plus diff, but it can also be used with tags and other Git objects.

Start with a problem

You're working in a Git repository and need to perform a specific task — but you're not sure which command or option is the right fit, or what this command can and cannot do.

Common uses

• inspect exactly what one commit changed
• verify what a tag points to
• expand HEAD, HEAD~1, or a hash into readable information

git show HEAD
git show HEAD~1
git show v1.2.0
git show --stat <commit>
git show --name-only <commit>

Best mental model

Think of git log as “list many commits” and git show as “open one object and read it carefully.”

Useful options

• --stat
• --name-only
• --name-status
• --no-patch

Important note

git show is read-only. It is safe to use while debugging, reviewing, and understanding history.

What problem this command solves in a workflow

In the workflow, git show is mostly a “inspect first, decide second” command. It usually does not rewrite history by itself; instead, it helps you confirm the current state of the working tree, index, refs, or commit objects.

Typical use cases

• Use git show before changing files or history so you have observable evidence first.
• Put git show into review, debugging, and incident-analysis flow so the team can align on the same context.
• When you need to explain why the repository looks the way it does, let git show surface verifiable information first.

Diagram view

Observed layers

Working treeIndexCommit historyRefs

→git show

Outputs

Console outputDiff contextDecision signal

If the output looks wrong, the first thing to question is usually the scope you inspected, not whether the command “worked”.

Special cases and boundaries

• Most inspection commands do not mutate history, but their output still depends on which HEAD, path, range, or ref you asked them to inspect.
• If git show shows something unexpected, first verify whether you are looking at the working tree, the index, the current branch, or a historical commit.
• Combining git show with git status, git log, and git diff is usually safer than trusting a single output in isolation.

Try it yourself

1. Practice the git-show command in a test repository and observe state changes before and after
2. Experiment with different options and compare the output differences
3. Simulate a real scenario where you would need to use this, and walk through the full process

Further reading

Keep going on the same topic:

• git-show-ref Tutorial
• git-sparse-checkout Tutorial
• git stash Tutorial