Inspecting history and diffs (log / show / diff / blame)

01 / 09

Tracing "when and why did this line change?"

The most frequent question encountered in team software development is:

> "When was this line written, by whom, and for what purpose?"

Developers regularly forget details of code they wrote months ago, or need to understand code written by others. The reason you create descriptive commits is precisely to answer this question.

The inspection commands in this chapter never alter repository state. You can run them freely and repeatedly without risk.

02 / 09

git log — Viewing commit history

git log displays the chronological history of commits from newest to oldest. Several options enhance readability:

--oneline … displays each commit as a single line (hash and commit message)
-n 3 (or -3) … limits output to the three newest commits
--graph … renders branch branches and merges as an ASCII graph
--stat … displays file change statistics (files modified, lines added/removed)

git log --oneline --graph is the standard command for getting a quick bird's-eye view of repository history.

$ git log --oneline -34d8b2f1 changed the button colour9f2a1c4 added the input box3b7e5d1 built the base

03 / 09

Inspecting specific branches without switching

Passing a branch name to git log lets you view that branch's history without switching branches.

Running git log --oneline fix lets you check progress on the fix branch from wherever you are currently working.

Remote-tracking branch names such as origin/main work the same way.

$ git log --oneline fix7c1e4a9 a quick fix3b7e5d1 built the base

04 / 09

git show — Inspecting specific commit details and diffs

While git log lists multiple commits, git show displays the complete details and code diff of a single specific commit.

Use git show HEAD for the latest commit, git show HEAD~2 for three commits back, or specify a commit hash directly like git show 4d8b2f1.

The output shows the author, date, message, and the exact diff of all changed files.

$ git show HEADcommit 4d8b2f1    changed the button colourdiff --git a/style.css b/style.css-button { color: navy; }+button { color: crimson; }

05 / 09

How to read diffs

The diff notation uses - and + markers:

Lines starting with - (red) … previous state (deleted lines)
Lines starting with + (green) … current state (added lines)
Lines without prefixes … unchanged context lines

Git treats editing a line as deleting the old line and adding a replacement line.

06 / 09

git diff — Comparing across Git areas

The targets of git diff change depending on options passed:

git diff … working tree ↔ staging area (uncommitted edits not yet staged)
git diff --staged … staging area ↔ HEAD commit (staged edits ready to be committed)
git diff HEAD … working tree ↔ HEAD commit (all uncommitted edits)
git diff HEAD~2 HEAD … commit ↔ commit (total difference between two commits)

Understanding git diff vs git diff --staged demonstrates why Git separates the staging area from the working tree.

07 / 09

Always inspect with git diff --staged before committing

git diff --staged serves as your pre-commit quality check.

It displays the exact diff that is about to be permanently committed to history.

Did you leave accidental debugging logs or comments behind?
Are unrelated edits inadvertently included?
Does the diff match the intended feature specification?

While git status lists modified file paths, git diff --staged shows the exact lines changed. Always run both before committing.

$ git diff --staged+function add(a, b) {+  return a + b+}+console.log("got this far")

08 / 09

git blame — Tracking line-by-line origin

git blame <filename> annotates every line of a file with the commit ID, author, and date that last modified it.

When wondering why an unexpected conditional statement exists, run git blame.

Once you identify the commit hash that introduced the line, run git show <hash> to read the original commit message and understand the design rationale.

$ git blame app.js3b7e5d1 (Alice 1) const ok = true9f2a1c4 (Bob   2) console.log(ok)

09 / 09

Investigate before fixing (practical approach)

Exercises in this chapter mirror real troubleshooting workflows.

The problem descriptions do not tell you which commit introduced a bug.

1. Use git log --oneline or git blame to find candidates
2. Inspect details with git show to confirm the root cause
3. Apply targeted fixes using git revert or git restore

Inspection commands are safe and non-destructive; run them as many times as needed.