Most git commands answer "what changed here?" The one I use most answers a different and much better question: when did this string first appear?

git log -S'some_string' -- path/to/file

That's it. It searches history for commits that changed the number of occurrences of that string. Added it, removed it, or changed how many times it shows up.

Why it beats the alternatives

git blame tells you who last touched a line. That's often useless, because the last touch was a reformat, a rename, or a lint sweep. Blame points at whoever ran prettier.

-S doesn't care about lines. It cares about the string existing. So it walks back past every cosmetic change and lands on the commit where the concept was introduced.

That commit usually has the message explaining why, which is the thing you actually wanted.

The debugging move

Here's the pattern I use constantly.

Something behaves oddly. You find the flag or constant responsible. You have no idea why it's set that way, and the code has no comment.

git log -S'FEATURE_FLAG_NAME' --oneline -- .

Three results. The oldest one says "disable X temporarily, see incident 412."

Three years ago. Temporarily.

The variant worth knowing

-S counts occurrences. -G takes a regex and matches any diff touching it, which catches "this line was modified" rather than "this string appeared or vanished." I start with -S because it's quieter.

Add --reverse to see oldest first. When you're hunting an origin, that puts the answer at the top instead of making you scroll.

Why I think it matters beyond git

The general skill is treating history as a queryable artifact rather than a log you occasionally scroll.

Almost every piece of strange code was reasonable when written. The context is usually recoverable — it's sitting in a commit message nobody has read since. Most "why on earth is this like this" questions have a documented answer, and the reason they feel undocumented is that people look in the files instead of the history.