git show

Definition

The git show command displays details about a Git object — most often a commit. For a commit it prints the log message together with the full diff of what changed, giving you a complete picture of a single revision. It can also reveal tags, trees, and the contents of a file as it existed at any point in history.

Reach for git show when you already know which object interests you and want to see everything about it on one screen. This page covers showing commits, reading the output, viewing a file at any revision, inspecting tags, the most useful options, and how the command differs from git log and git diff.

Showing a commit

With no arguments, git show displays the most recent commit (HEAD): its author, date, message, and the changes it introduced.

git show

To inspect any other commit, pass its hash, a branch name, or a relative reference:

git show a1b2c3d        # by abbreviated hash
git show HEAD~2         # the commit two steps before HEAD
git show main           # the tip of the main branch
git show HEAD@{1}       # where HEAD pointed one move ago (via the reflog)

The output combines what you would get from git log and git diff for that one commit.

Reading the output

A typical commit display has a header followed by a unified diff:

commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
Author: Jane Dev <[email protected]m>
Date:   Mon Jun 9 14:02:11 2025 +0200

    Fix off-by-one error in pagination

diff --git a/src/page.js b/src/page.js
index 83db48f..f735c2e 100644
--- a/src/page.js
+++ b/src/page.js
@@ -10,7 +10,7 @@ function pageStart(page, perPage) {
-  return page * perPage;
+  return (page - 1) * perPage;
 }

The header names the commit, who authored it, and when. The diff --git block shows the change: lines starting with - were removed, lines starting with + were added, and the @@ ... @@ hunk header tells you the line numbers affected. This is the same patch format you see from git diff.

Viewing a file at a specific revision

A powerful trick is to print a file exactly as it looked in a given commit, without checking anything out. Use the <commit>:<path> syntax:

git show HEAD~3:src/index.js

This streams the old version of index.js to your terminal, leaving your working tree untouched — ideal for comparing or copying a snippet from the past. The path is taken from the repository root, not your current directory. To inspect the staged version of a file, use a colon with no commit:

git show :src/index.js   # the file as currently staged in the index

Inspecting tags

When you point git show at an annotated tag, it prints the tag message and tagger information, then the commit the tag refers to:

git show v1.0.0

This is the quickest way to see who created a release tag and what it points at. See git tag for creating them. A lightweight tag has no metadata of its own, so git show jumps straight to showing the commit it labels.

Showing several objects at once

git show accepts more than one argument and prints each object in turn, newest first. This is handy for reviewing a small set of related commits without scrolling through full history:

git show HEAD HEAD~1 v1.0.0

Useful options

By default git show includes the full diff. The options below trim or reshape that output:

git show --stat HEAD         # summary of files changed and line counts
git show --name-only HEAD    # just the changed file names
git show -s HEAD             # suppress the diff; show only the commit message
git show --pretty=oneline HEAD   # compact one-line header
git show --format="%an %s" -s HEAD   # custom format: author name + subject

The --format (and --pretty) placeholders are shared with git log: %an is the author name, %s the subject line, %H the full hash, and %ad the author date.

Common options

git show vs git log and git diff

These three commands overlap but serve different needs. git log walks a range of commits and is built for browsing history. git diff compares two arbitrary states. git show zooms in on one object and tells you everything about it — making it the natural choice when you already know which commit you care about.

A common workflow is to find a commit's hash with git log or git blame, then pass that hash to git show to read the full change in detail.

Practice