Inspection & Blame Tools

A test that passed on Monday fails on Thursday. Somewhere between those two days is a commit. This module is about finding it in minutes instead of guessing for an hour.

Why This Module Matters

Every repository is a complete forensic record of how the product got to its current state. Almost nobody uses it that way. The typical investigation is a message in the team chat — "did anyone change the login button?" — followed by twenty minutes of silence.

git blame answers that question directly: for every single line of a file, it names the commit, the author and the date that last touched it. And when the line you care about has already been deleted, the pickaxe searches — git log -S and git log -G — find the commit where a given string entered or left the codebase, anywhere in history.

A word on the name. "Blame" is a terrible label for a genuinely neutral tool. What you are producing is a timeline and a person to ask, not a culprit. The most valuable output of a blame investigation is usually a two-minute conversation with the one developer who remembers why.

What You'll Learn

• Reading git blame output: commit, author, timestamp, line number, content
• Narrowing blame to a line range with -L so you're not reading 900 lines
• Seeing past a whitespace-only reformat with -w, and following a file across renames
• git log -S "string" — the commits where a string's occurrence count changed
• git log -G "pattern" — the commits whose diff matches a regular expression
• Turning findings into a bug report a developer can act on immediately

Pro Tip

Pair git blame with git show <commit>. Blame tells you which commit; git show tells you what else that commit changed — which is very often the actual explanation.