Lesson 19 of 30

git blame and git bisect

Q: Production is showing a regression that wasn't there a few weeks ago, across an unknown number of commits. How would you use Git to find the exact commit that introduced it?

A strong answer covers: Reaches for git bisect, not manual commit-by-commit inspection, given an unknown range of commits; Explains the binary-search mechanic: mark a known-good and known-bad commit, test the midpoint, repeat; Mentions automating it with git bisect run and a script/test that exits nonzero on failure; Knows to git bisect reset afterward to get out of detached HEAD.

Two tools for the same detective work: blame tells you who touched a line and when, bisect finds which commit out of hundreds actually broke something.

15 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on git blame and git bisect

What interviewers actually ask about this, and what a strong answer has to cover.

Production is showing a regression that wasn't there a few weeks ago, across an unknown number of commits. How would you use Git to find the exact commit that introduced it?

A strong answer covers

Reaches for git bisect, not manual commit-by-commit inspection, given an unknown range of commits
Explains the binary-search mechanic: mark a known-good and known-bad commit, test the midpoint, repeat
Mentions automating it with git bisect run and a script/test that exits nonzero on failure
Knows to git bisect reset afterward to get out of detached HEAD

Likely follow-ups

What happens to your bisect search if one of the commits in the range simply doesn't build — how do you handle that?
How is what git blame tells you different from what git bisect tells you? Could you use blame instead here?
If the bug is flaky and only reproduces some of the time, what goes wrong with a plain bisect session?

Practice these with the AI interviewer →

The plain-language idea

git blame answers "who last changed this line, and in which commit?" — you point it at a file and it annotates every line with the commit, author, and date that introduced it. git bisect answers a harder question: "somewhere in these 400 commits, something broke — which one?" It works by binary search: you tell it one commit that's known-good and one that's known-bad, and it checks out commits in between, asking you each time "good or bad?", until it isolates the exact commit.

Blame is for understanding one line. Bisect is for hunting a regression across a range you can't manually inspect.

See it in a real thing: blame on a suspicious line

$ git blame -L 40,45 src/lib/formatCurrency.ts
a1b2c3d4 (Priya Nair    2026-06-02 11:14:03 +0530  40)   if (amount < 0) {
a1b2c3d4 (Priya Nair    2026-06-02 11:14:03 +0530  41)     return `-${symbol}${Math.abs(amount)}`;
f9e8d7c6 (Adesh Shukla  2026-08-19 09:41:22 +0530  42)   }
f9e8d7c6 (Adesh Shukla  2026-08-19 09:41:22 +0530  43)   return `${symbol}${amount.toFixed(2)}`;

-L 40,45 scopes it to a line range instead of the whole file. Each line shows the commit hash, author, timestamp — enough to run git show f9e8d7c6 next and read the actual commit message for why, not just who.

Now bisect: a currency-formatting bug shipped somewhere in the last 60 commits and nobody's sure exactly when.

git bisect start
git bisect bad                 # HEAD is broken
git bisect good v2.3.0         # this tag was known fine

Git checks out a commit roughly halfway between the two:

Bisecting: 29 revisions left to test after this (roughly 5 steps)
[c4b3a21f] fix: correct pagination offset on last page

You test that commit — run the app, run a script, whatever tells you good or bad — then tell Git:

git bisect bad   # or: git bisect good

Repeat. Each answer halves the remaining range. After roughly log2(60), about 6 steps, Git prints the culprit:

f9e8d7c6b5a4938271605f4e3d2c1b0a9f8e7d6c is the first bad commit
commit f9e8d7c6b5a4938271605f4e3d2c1b0a9f8e7d6c
Author: Adesh Shukla <adesh@example.com>
Date:   Wed Aug 19 09:41:22 2026 +0530

    refactor: simplify negative-amount formatting

Clean up with git bisect reset to return to where you started.

What people usually miss

Watch out

Blame shows the last commit to touch a line, not necessarily the commit that introduced the bug. A one-line whitespace reformat or a rename can "blame" onto someone who never touched the actual logic. git blame -w ignores whitespace-only changes, and git log --follow -p -- file walks further back through renames.
Bisect needs a genuinely binary good/bad signal, or it lies to you. If the bug is flaky (only reproduces sometimes) or the "bad" commit doesn't actually build, a wrong answer at any step sends the whole search down the wrong half. git bisect skip exists for commits you can't test (e.g. broken build unrelated to the bug).
You still have to reset when you're done. Bisect leaves you in a detached HEAD on whatever commit it last checked out — git bisect reset puts you back on the branch you started from. Forgetting this is how people end up confused about why they're not on main anymore.

The genealogy: bisect's checkouts land you in detached HEAD

Every step of git bisect checks out a commit directly rather than a branch — the exact same detached-HEAD state you land in any time you check out a raw commit hash. Understanding why HEAD can point straight at a commit instead of at a branch name is what makes bisect's behavior (and the need to reset afterward) make sense instead of feeling like a special case.