Command Reference

git show

Inspect a specific commit, tag, or object in detail, making it one of the most useful commands for reading history precisely.

Who This Is For
  • Developers who already know basic commit and branch actions
  • Readers who want to understand command boundaries and risk
Prerequisites
  • A basic mental model of worktree, index, and commits
  • Comfort reading `git status` and a small commit graph
Common Risks
  • Using local cleanup commands on already shared history
  • Continuing to rewrite before confirming a recovery path

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.

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

Where inspection commands operateThese commands mainly read repository state and emit information. The key is knowing which layer you are observing.
Observed layers
Working treeIndexCommit historyRefs
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.