二分查找：追踪问题提交

A bug hides somewhere in your last 200 commits. git bisect runs a binary search through history, halving the suspect range with each test.

Checking 200 commits linearly means 200 tests. Binary search needs only about log2(200) ≈ 8 — bisect narrows the culprit dramatically faster.

Kick off a session with git bisect start. From there Git walks you through marking commits as good or bad.

Tell Git where the bug exists (bad) and an older commit where it didn't (good). That bounds the search range.

Git checks out the midpoint commit. You test it and report good or bad, and Git picks the next midpoint accordingly.

After a few rounds, Git names the first bad commit — its hash, author, and message — the exact change that introduced the bug.

Always finish with git bisect reset. It returns you to your starting branch and clears the bisect state.

If you can test the bug programmatically, git bisect run ./test.sh automates the whole search — exit 0 means good, non-zero means bad.

Hit a commit you can't test (it won't build)? git bisect skip tells Git to try a nearby commit instead.

git bisect log saves or replays the decisions you made — useful for documenting how you found a bug or resuming a session later.

For reliable bisects: have a clear, reproducible test, keep commits small and atomic, and automate with git bisect run whenever you can.

Recap: git bisect start, mark good and bad, test each midpoint to halve the range, automate with run, skip the untestable, and reset when done.