Reading history
Something's broken, nobody remembers changing it, and forty commits stand between you and the answer.
Anvesha pings the group chat with a screenshot: the homepage preview you've been sending the Board looks off. The section spacing near the footer has gone from a clean 24px gap to something like 4px — cramped, wrong, definitely not what anyone designed. "Did one of you touch this? It was fine Monday."
Nobody remembers touching it. There have been maybe forty commits since Monday — yours, Rachit's, Anvesha's, and two from Sahil who's been setting up the build config. The bug is real, it's live on the preview, and right now your only lead is "somewhere in the last forty commits."
This is the moment git log stops being a curiosity and starts being a search tool.
1. git log — scanning the whole trail
Plain git log is unusable for this — forty full commit messages scrolling past. You want a shape you can actually scan:
Three suspects out of forty, immediately, just by asking Git "which commits actually changed the file that's misbehaving." That single -- path filter does more work than reading every message would have.
git log --author="sahil" — only one person's commits. git log --since="3 days ago" — only recent ones. git log --grep="spacing" — only messages mentioning a word. git log -S"padding" — only commits that added or removed the literal string "padding" anywhere in the diff, which is often the single fastest way to find where a specific value came from.
2. git show — opening one suspect fully
"chore: tidy footer spacing variables" sounds exactly like the kind of change that could quietly break spacing. Open it completely — message, author, full diff:
Found it. Sahil renamed a variable he thought was unused and, in the process, typed 4px instead of copying the original 24px across. Not malicious, not even careless in an obvious way — just a small slip that git show surfaces in about four seconds once you know which commit to point it at.
3. git diff — comparing any two points
git show is one commit in isolation. git diff is for comparing across a range — useful once you want to see everything that changed between "known good" and "known broken":
| Command | Compares |
|---|---|
git diff | Working directory vs staging |
git diff --staged | Staging vs last commit |
git diff HEAD~5 | Working directory vs five commits ago |
git diff main..feature | Two branches |
git diff 3f8a1b2 c9d4e5f -- src/styles.css | Two specific commits, one file only |
4. git blame — who touched this exact line, and when
Suppose the log filter hadn't been so clean — suppose you just knew "the footer spacing is wrong" and nothing else. git blame annotates every single line of a file with the commit that last changed it:
Same answer, arrived at from the opposite direction: instead of guessing which commit to open, you start from the broken line and let Git tell you which commit is responsible. The name in the output isn't an accusation — it's a pointer to context. You now know exactly who to ask "hey, was this rename intentional?" instead of posting "did anyone touch the CSS??" into a group chat and hoping.
5. git reflog — the log of where HEAD has been
Separate from all of the above: git reflog doesn't track your project's history, it tracks your local movements through it — every checkout, every commit, every reset, on this one machine, for about 90 days. It's not what you needed for today's bug hunt, but hold onto it, because in the next chapter you're going to make a genuine mistake, and this is what gets you out of it.
git config --global alias.lg "log --graph --oneline --all --decorate" — now git lg shows every branch as a visual graph in one line per commit. When the club's history has more than one branch running at once (Chapter 7 onward), this becomes the fastest way to see what's actually going on.
show then gives you the full story of that commit: message, author, diff. Reflog answers a different question entirely (where has my HEAD been), and scanning forty log entries by eye is exactly the slow path blame exists to skip.
You message Sahil the commit hash and a screenshot. He replies within a minute: "oh no, yeah, that was a typo, I meant to keep it at 24." Simple enough fix — except the commit is already sitting in the shared history, two commits behind your current work, with another commit from you already stacked on top of it. Just editing the line again feels wrong somehow. Is there a correct way to undo this specific, already-buried mistake without disturbing anything that came after it?