In Git, how do you use git bisect to find the commit that introduced a bug?

## What bisect is for You know something worked in the past and is broken now, but not which of hundreds of commits broke it. Reading every diff is linear work. `git bisect` turns the hunt into a binary search over history: each test halves the suspects, so about log2(N) tests isolate the culprit among N commits. A thousand commits become roughly ten tests. ## Marking the endpoints A bisect needs two anchors: a commit where the symptom is present (`bad`) and an ancestor where it is absent (`good`). Open the session with `git bisect start`, then: - `git bisect bad` marks the checked-out commit as broken; `git bisect bad <rev>` marks a named one. - `git bisect good <rev>` marks a known-working ancestor. You may pass several good commits. - `git bisect start <bad> <good>` does both in one line. Once Git has one bad and at least one good commit it computes the set of commits reachable from bad but not from good, picks one near the middle, and checks it out. ## The test loop Each step Git prints something like `Bisecting: 12 revisions left to test after this (roughly 4 steps)` and leaves you on a detached HEAD at the candidate commit — you are not on a branch, so do not commit there. Build, reproduce (or fail to reproduce) the symptom, and answer `git bisect good` or `git bisect bad`. Answer about the same symptom every time; changing what you test mid-search produces a meaningless result. Git records answers under `refs/bisect/*` and in `.git/BISECT_LOG`, so the state survives shells. ## Reading the result When the range collapses to a single commit, Git prints `<sha> is the first bad commit` followed by the author, date, message and changed files. First bad means the earliest commit, in the searched range, from which the symptom is present — the boundary between good and bad, not necessarily the commit whose diff looks guilty. It may merely expose a latent defect introduced earlier. ## Ending the session `git bisect reset` deletes the bisect refs and checks out the branch you were on when you started; `git bisect reset <commit>` lands you somewhere else instead. Leaving a session open is the classic beginner trap — you stay on a detached HEAD and later wonder where your work went. `git checkout` on its own does not clear bisect state. ## Session tools `git bisect log` prints the answers so far; redirect it to a file and `git bisect replay <file>` re-runs them, which lets you undo a mistaken answer by editing the log. `git bisect visualize` (alias `view`) shows the remaining candidates. `git bisect start -- <path>` restricts the search to commits touching given paths, which can cut the candidate set sharply when you know the subsystem. ## Preconditions Bisect assumes a clean working tree (stash or commit first) and that every candidate commit can actually be built and tested; commits that cannot be judged are handled with `git bisect skip`. It also assumes monotonicity: the symptom appears once and stays. An intermittent, flaky symptom makes answers unreliable, and one wrong answer sends the whole search into the wrong half.