6 exercises — narrate a git bisect session, read git blame output, and report commit archaeology findings in clear, blameless English.
0 / 6 completed
1 / 6
You are starting a `git bisect` session to find which commit introduced a regression. Which is the correct narration for your team channel?
`git bisect` performs a binary search across commit history: you mark a known-good and known-bad commit, and git checks out the midpoint for you to test, repeating until it isolates the exact commit. Narrating the bisect should state the good/bad boundaries and the goal (finding the offending commit).
Formula: "Starting a git bisect between [known-good] and [known-bad] to find the commit that introduced [regression]."
Vocabulary: "known-good commit / good ref" (last commit without the bug), "known-bad commit / bad ref" (first commit with the bug confirmed), "bisecting" (binary search through history), "narrowing down" (the iterative process of testing midpoints).
2 / 6
Mid-bisect, git checks out a commit and you need to report whether it has the bug. Which phrasing correctly follows git bisect convention?
Each bisect iteration follows the same pattern: test the checked-out commit, then explicitly report it as "good" or "bad" (matching `git bisect good` / `git bisect bad`) so the process narrows correctly.
Formula: "Testing this commit — the bug [reproduces/does not reproduce] here, marking it [bad/good] and continuing."
Note: if a commit doesn't build or can't be tested (unrelated breakage), the correct git command is `git bisect skip` — you should never mark a commit "good" just because it fails to compile; that would corrupt the bisect result.
3 / 6
Git bisect has isolated the offending commit: a 400-line refactor PR. Which is the correct way to report the finding?
Reporting a bisect result should include the commit hash, commit message/PR reference, and be honest that isolating the commit is not the same as identifying the exact line — a large commit still requires further investigation.
Formula: "Bisect narrowed the regression down to commit [hash] ([message/PR]). [Caveat about further work needed, if any]."
Bisect finds the commit that introduced a bug; it does not automatically explain why. Especially for large refactor commits, the next step is usually reading the diff closely or writing a targeted test to isolate the exact change.
4 / 6
You run `git blame` on a suspicious line and see it was last touched by a commit from 3 years ago with the message "misc fixes." What is the correct next step and how do you narrate it?
`git blame` shows the most recent commit to touch a line, which is sometimes an uninformative "misc fixes" or formatting commit that obscures the original author's intent. The correct move is to go further back in history — e.g. `git log -p --follow ` or `git blame -w` (ignoring whitespace) or checking blame on the parent commit — to find the commit that actually introduced the logic.
Vocabulary: "commit archaeology" (digging through history to understand why code exists), "blame points to" (what git blame reports), "-w flag" (ignore whitespace-only changes when blaming), "--follow" (track a file through renames).
5 / 6
Your `git bisect` result and your `git blame` investigation both point to the same author. What is the professionally correct way to reference this in a post-mortem or bug ticket?
Commit archaeology should be used to understand what changed and why, never to publicly assign blame to an individual. The professional framing focuses on the specific code change and the systemic gap (missing test coverage) that allowed it through review.
Formula: "The regression was introduced in [commit] during [context] — the change [specific technical cause]. No individual blame; [systemic gap] allowed it through."
This mirrors blameless post-mortem culture: `git blame` is a technical tool for finding which change caused a bug, not a tool for assigning personal fault — the name is unfortunately misleading.
6 / 6
A colleague suggests skipping bisect entirely and just "reading through recent commits" to find a regression in a 200-commit range. What is the correct response?
Bisect's efficiency comes from binary search: to isolate 1 commit among N candidates requires roughly log₂(N) tests — for 200 commits, about 8 tests, versus up to 200 manual checks. Explaining this trade-off in concrete numbers is a persuasive, correct way to advocate for bisect over manual searching.
Formula: "Manually checking [N] commits would take much longer — bisect only needs about log2([N]) ≈ [count] tests to isolate the exact commit."
This is also a good moment to mention `git bisect run