git blame: who touched this line?

Every line has a story

Sooner or later you will stare at a line of code that makes no sense — a weird constant, a check for a case that seems impossible — and need to know why it exists before daring to touch it. Deleting a line you don't understand is how bugs that someone already fixed come back. This exact investigation happens weekly in real jobs, and Git has a dedicated command for it.

git blame <file> prints the file with, for each line, the last commit that touched it:

$ git blame pancakes.txt
a1b2c3d (Ada Lovelace 2026-03-03 1) Pancakes
a1b2c3d (Ada Lovelace 2026-03-03 2) - flour
a1b2c3d (Ada Lovelace 2026-03-03 3) - eggs
f0e9d8c (Ada Lovelace 2026-03-04 4) - oat milk

Line 4 was last changed by commit f0e9d8c. Feed that hash to git show (lesson 3-1) and you get the commit's message and full change — the "why" you were after. Despite the accusatory name, blame is mostly used for context, very often on your own lines.

This is also where lesson 3-3 pays off: blame leads you to a commit message, and that message is either "Guard against empty carts, they crash the total" or fixed stuff.

Searching history when blame isn't enough

Blame answers "who last touched what's there now." Two more searches cover the cases blame can't:

• git log --oneline -- pancakes.txt — the history of one file: every commit that touched it, even if the file was later renamed or the lines rewritten. (The -- separates the file name from other arguments.)
• git log -S "oat milk" --oneline — commits whose changes added or removed that exact text, anywhere in the project. Engineers call this the pickaxe. It finds the commit that deleted something, which blame cannot do, because the deleted line no longer exists to be blamed.

Together with git log and git show, these make history a searchable database of decisions rather than a pile of old versions — the payoff for all those careful commits.