<aside> 🔀
Module 4 — Reading History (git log, show, diff ranges). A repository's value is its history — but only to people who can interrogate it. This module turns the parent chain you saw in Module 3 into answers: what happened, when, by whom, to which files, and what exactly changed. These are the commands you will run during incidents, reviews, and every "who touched this?" conversation.
🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start. You need Module 2 (the kitchen repository, which this module keeps reading) and Module 3 (commits chained by parent pointers; HEAD; hashes). Tools: just Git and a terminal.
</aside>
<aside> 📖
Official docs: git-log manual · Git Book §2.3 — Viewing the Commit History
</aside>
git log does exactly what you did by hand in Module 3, tirelessly: start at HEAD's commit, print it, follow its parent pointer, print that, and so on until a commit with no parent (your root commit). Newest first, because the chain only points backwards. Plain git log prints each commit's hash, author, date, and full message; git log --oneline compresses each to one line — short hash plus subject — and is the form you will type most, because history questions usually start with a skim.
🧪 Exercise 4.1 — the full log, then the skim view
cd ~/git-course/kitchen
git log | head -12 # first two entries of the full form
git log --oneline # the whole history, one line each
<aside> 🗞️
Real-world analogy — the ship's logbook
A ship's logbook is written forward but read backwards: when something goes wrong, the captain starts at the latest entry and works back toward the cause. Each entry is dated, signed, and explains itself. git log is that reading: newest first, every entry signed (author), self-explaining (message) — and the skim view is running your thumb down the margin dates until something catches your eye.
Where the analogy stops working. A logbook has one line per event, chosen by whoever held the pen. Git's log is derived from the snapshots themselves — it can be re-rendered with any level of detail after the fact: one line per commit today (--oneline), full patches tomorrow (-p), only entries touching one file the day after (-- <path>). You are not reading a fixed document; you are querying a database that can print itself a thousand ways.
</aside>
<aside> 📖
Official docs: git-log manual
</aside>
The log's message says why; two flags add the what. git log --stat appends a per-file change summary to each entry (which files, how many lines). git log -p appends the full patch — the actual diff each commit introduced, computed on demand between the commit's snapshot and its parent's (Module 3's "diffs are derived, not stored", visible live). -p output gets long; combine with -1, -2 (limit to N commits) or a path filter from A3.
🧪 Exercise 4.2 — one commit, three zoom levels
cd ~/git-course/kitchen
git log --oneline -1 # zoom 1: subject only
git log --stat -1 # zoom 2: which files, how much
git log -p -1 # zoom 3: the exact lines (q to quit the pager)
<aside> 📖
Official docs: git-log manual · Git Book §2.3 — Viewing the Commit History
</aside>
Real repositories have tens of thousands of commits; nobody scrolls. You filter. The everyday six: -N (only the N newest), --author="name" (by committer), --grep="text" (search commit messages), --since="2 weeks ago" / --until="2026-01-01" (time windows, and yes, plain English works), and — the one you will use most — -- <path>: only commits that touched that file or directory. The -- separates revisions from paths (you saw Git itself suggest this convention in an error message once; now you know what it disambiguates). Filters combine freely: git log --oneline --author=Rahman --since="1 week ago" -- deploy/ is a sentence: what did Rahman change under deploy/ this week?