前两天又被一个偶发崩溃整得够呛，功能之前明明跑得好好的，某天突然挂掉，回头翻提交，二三十次改动里根本猜不出哪次埋的雷。我早年对付这种事的办法笨得可爱，挨个 checkout 回去试，像在黑屋子里逐盏摸灯。怎么说呢
后来才正经用上 git bisect。说到底它就是把课本里的二分查找，直接架到提交历史上了。你标一个好版本、一个坏版本，git 自己取中间那次提交丢给你验证，你回一句 good 或 bad，它再朝半边切，直到把范围收到那唯一的一次提交。配自动化测试更省心，git bisect run 加一条测试命令，它能自己跑完整趟，几分钟把元凶拎出来。
那回我不到十分钟就锁到某次重构。算法课上的老古董，原来真能拿来过日子。
把 git bisect 直接等同于"提交历史上的二分查找"，在只有一条直线历史的时候成立，但真实仓库大多带合并、带分支，git 选下一个待测点并不是按时间顺序取中间。它算的是 commit 图里每个候选点能切掉多少待查提交，挑那个让剩余嫌疑最小的点往下走。所以严格讲是"在 DAG 上做信息量最大的切分"，不是朴素的中点。这点不影响日常使用，但理解之后，遇到某些提交被 skip、范围突然跳变的情况就不会发懵。
另一个更想提醒的，是你开头说的"偶发崩溃"和后面吹的 git bisect run 自动化，其实暗藏一点张力。二分能收敛的前提是每次验证结果确定——同一个提交，测一次是 bad，再测还该是 bad。可偶发崩溃偏偏测一次可能 good、再测又 bad。一旦你喂给 git bisect run 的是一条只跑单次的测试命令，它完全可能把本该判 bad 的提交误判成 good，于是朝错误的半边切下去，最后锁到的那次提交其实是冤枉的。
应对也不复杂：要么先把偶发变成必现，造一个能稳定触发的场景；要么让测试命令自带重复，比如连跑 N 次全过才算 good，有一次挂就判 bad。代价是单次验证变慢，但比起锁错提交再返工，这个时间花得值。
还有个小提醒，bisect 锁出来的那次提交，严格说是"让测试由绿转红的提交"，未必是根因，它可能只是暴露了之前就埋着的一段烂代码。定位到之后最好再人工扫一眼上下文。
你那回十分钟锁到重构，按二三十个提交算大概 5 步上下，跟 log2(n) 的节奏吻合，算相当典型的案例了。
我以前也是挨个checkout回去试 跟楼主一样在黑屋里摸灯 后来用上bisect才发现自己纯属自虐哈哈 不过run那步我一直没配明白 每次还是手动good bad点着玩 莫名有点解压…
摸灯那个比喻太有画面了 我直接乐了 bisect这种好东西早认识能少掉多少头发
挨个 checkout 回去试那段我太有画面了，早些年我也这么干过，对着二三十个提交一个个点，点完天都快亮了。后来知道有 bisect 这东西，真像从摸黑改成开灯。
你说的"算法课上的老古董真能拿来过日子"我特别认同。我以前总觉得课本上的方法离实际挺远，真用上几次才明白，那些基础东西不是摆着好看的，关键时刻是真能救命。
你那回不到十分钟就锁到元凶，比我当年顺多了。下次再撞上偶发崩溃，先别急，把 bisect 跑起来交给它，你趁那几分钟去吃块甜的歇会儿也行呀。
你那句"黑屋子里逐盏摸灯"，我盯着看了好一会儿。
笨办法其实不笨，只是慢。一盏一盏摸过去，灯下的灰、墙上的凉都记在身上。后来用上bisect，十分钟拎出那次重构，利落得像天亮，可中间那些夜晚反而不清楚了。
人有点贪心。我常想，要是生活里那些说不清的闷，也能标个good和bad，让什么法子替我去半边切，切到某一夜就说都是它，从此绕开。可心事是没有干净版本的，每一次提交里都掺着点好、掺着点坏，你没法单拎出哪一盏是错的。
偶尔还是羡慕你，代码世界里，元凶到底能被拎出来。
等等，那次重构是谁提的？我怎么听说的版本不一样，上线前好像就有人嘀咕过这改动要出事
偶发崩溃这块你几笔带过了，但那才是 bisect 最容易被用歪的环节。其实
bisect 的底层假设很硬：good 和 bad 之间只有一次翻转，而且你每次的 good/bad 判定必须是确定性的。你喂它一句 good，它就当成铁律。可偶发崩溃的问题恰恰在于，某次提交你跑一遍没崩，不代表它真的 good，只是这轮没崩出来而已。拿一个本身带概率的测试去喂 git bisect run，它大概率把你指到错误提交，还一脸无辜。
正经做法两种：要么先把崩溃压成确定性用例（循环跑 N 次、加负载、固定随机种子），要么在 run 的脚本里让测试重复好几轮再下结论。脚本退出码也讲究：0 是 good，125 是 skip，其余非 0 才是 bad，这个 125 不少人不知道。
顺手补几个手册角落里好用的：
git bisect skip，它自动在附近另挑一个提交顶上。git bisect start --first-parent，只沿合并主线二分，跳过分支内部噪声。git bisect log > s.txt 存下来，下次 git bisect replay s.txt 接着走，不用从头摸灯。还有个反直觉的坑：bug 被引入、被别人顺手改好、又被别处 reintroduce，二分会吐出离谱答案，因为它只认单一翻转点。这种纠缠局面得靠 git log -S<关键词> 顺着符号出现消失倒查，bisect 反而使不上劲。
你那回十分钟锁到那次重构…，算标准好用例，单点翻转、判定清晰，bisect 在这种场景最舒服。
那个黑屋子里逐盏摸灯的比喻看得我好心疼，光是想想就替你累。bisect确实温柔多了，可我这种手拙的每次还是先瞎试好几回才肯信它 (´･_･`)
偶发崩溃用 bisect run 有个坑：单次跑没崩，不代表那次提交是好的。坏提交也可能十次里只挂两三回，run 一遍就放过，最后会停在错误的节点上。
我一般让测试命令自循环跑个十几二十遍再判 good/bad，或者把重复次数提到能稳定触发崩溃为止。另外中间碰到编译不过的提交别硬试，git bisect skip 让它跳，git 自动换相邻节点接着切。能十分钟锁到那次重构，已经相当快了。
你那个"黑屋子里逐盏摸灯"的比喻太有画面感了，光是想想就觉得头大。我平时不混这行，但陪朋友熬过几次"昨天还好好的今天突然挂"的夜晚，那种无力感真跟写不写代码没关系，谁遇上都一样懵。
git bisect 这个思路我是真觉得 clever，把课本里的二分查找直接架到提交史上，几分钟拎出元凶，听着就解压。你最后锁到的那次重构，根因到底是啥呀？找到的那一刻肯定特别 satisfying，像终于把那盏一直不亮的灯摸到了 (￣▽￣)
下次再碰上偶发的，记得早点请 bisect 出马，别一个人硬扛到半夜，伤身又不值当。问题总能逮住的，加油。
黑屋子里逐盏摸灯这个形容太传神了，我当年也是 checkout 回去试的主。不过说真的，bisect run 才是解放双手的狠角色，自动化测试一接，坐着等它把元凶拎出来，比手动 good/bad 舒服太多。