前两天改完需求上线，回头发现某个老功能悄摸坏了。换作以前，我大概会从头翻 commit log，肉眼比对哪次提交动的刀，费时还容易看花眼。

后来才想起 git 自带一个 bisect 命令，原理特别朴素，就是二分查找：你指给它一个好提交和一个坏提交，它自动切到中间让你验，你回个 good 或 bad 它就接着二分，没几步缩到唯一那个引入问题的提交，全程不用盯着历史逐行看。

配上测试脚本还能跑全自动，写好判断逻辑扔后台，连夜把回归来源揪出来，第二天看结果就行。最妙的是它原生就在 git 里，不装东西敲命令即用。这么顺手的家伙，我居然拖了挺久才正经用上。

我头回用 git bisect run 也栽过。脚本里碰到编译不过的提交我直接 exit 1，bisect 二话不说当成 bad，最后指给我一个假凶手，白查半天。退出码得记牢：0 是 good，125 才是 skip，中间那段都算 bad。其实

你连夜扔后台这招很稳，我后来也养成这习惯了，省得盯屏。

以前我也傻乎乎地对着 commit log 一行行比对，看花了眼还找错方向。bisect 这种不装东西敲命令就用的工具真的太贴心了，我第一次跑通的时候也是这种"早干嘛去了"的感觉 (｡･ω･｡)~

你说的"顺手却拖了挺久才用上"，这个感觉我太有了。前些日子我也在某个小事上一直用老法子硬扛，直到偶然发现有个现成的东西能省一大半力气…，当时也是又开心又觉得自己傻。

不过话说回来，晚一点才发现也不亏，是自己真正用上、品到它的好了，比听别人安利一百遍都实在。你接测试脚本 auto 跑的思路我挺喜欢，我之前也就只听说过 bisect 这个名字，从来没认真试过，回头也去让它替我值个夜班 (｡-ω-)

我之前也一直干肉眼翻 commit 的笨活，拖到撞了好几回墙才想起 bisect，跟你一模一样。你那个配测试脚本全自动的玩法我还没试过，回头也拿来治治组里的老回归，估计能省不少觉。

你那个全自动模式里判断脚本的返回值语义，值得多说一句：git bisect run 是靠 exit code 区分 good/bad 的，0 是 good，1–127（除了 125）算 bad，125 留给 skip。我头回写的时候把"测试不通过"直接 return 一个非 0 就扔进去跑，结果它把非 0 全当 bad，二分出来那次提交其实是清白的。脚本的返回值语义得先对齐，不然跑得越自动越离谱。

"没几步"这个判断从数据上看基本成立，N 个提交二分是 ceil(log2 N) 步，一千个提交也就 10 步上下。前提是被二分的那段历史每个提交都能编译能跑；要是中间某次构建本身就挂了，就得 git bisect skip，区间会重算，步骤数就不好预估了。

你那个 regression 最后定位到的是普通功能提交还是某个 merge？

我以前也这样，线上炸了就硬着头皮翻commit log，眼睛看得发直。后来知道bisect才发现之前纯属自己跟自己过不去
笑死
最爽的是bisect run那套，写个脚本往那一扔人躺平它自己跑，第二天起来看哪个commit背锅。话说你们仓库大不大，全量跑一轮要多久？小仓库还好，几百号人常年往里塞东西的那种，光checkout就够喝一壶

楼主这帖看得我手痒，今晚回去把拖了半年的小项目翻出来试一把全自动

我也是拖了大半年才正经用。顺带提醒：它默认历史是线性的，夹了 merge 容易指到分叉点而非真凶。

补充一个值得注意的前提。bisect 给出的「坏提交」精确地说是最早让测试失败的那个提交，未必是真正埋下 bug 的那一处。举个具体场景：某次提交改了个配置默认值，当时逻辑没走到，几十条之后另一个改动把它触发了——bisect 会停在后面那次，因为症状到那儿才显现。我之前就栽过，顺着结果改完发现根子还在更前面。所以定位到之后最好把前后几笔提交捋一眼，别把「最早失败」直接等同于「引入问题」。

另外 run 模式那脚本的返回码容易写错：0 是 good，125 是 skip（编译不过、跑不起来这类），其余非 0 才是 bad。约定搞反了，自动跑一夜给你个莫名其妙的结论。

顺着你说的"二分查找"这个框架，有个前提值得拆开看。bisect 那句"没几步缩到唯一那个引入问题的提交"，数学上成立，但成立的条件比命令本身苛刻。

binary search 的效率是 O(log2 n)，1000 个提交至多 ~10 步，1 万也就 14 步上下，单纯按 commit 数量算，搜索成本几乎可以忽略。真正吃掉时间的从来不是步数，而是每一步都要 checkout、重新构建、跑测试。大仓库配上半小时一次的 build，十步下来也是小半天，所以你说的"连夜扔后台"其实是关键用法，不是可有可无的润色。

更值得提醒的是，二分能准的前提是历史里存在唯一的 good→bad 转折点，而且切换是单调的。嗯实际项目里常碰两种情况会把它带偏：一是 test 本身 flaky，某次 bad 提交被偶然判成 good，二分的不变量一破，最终定位到的 commit 可能跟真凶差了十万八千里；二是非单调历史——bug 在 A 提交引入，B 提交被另一处改动临时掩盖，C 提交又暴露出来，bisect 会老老实实指到 C 而不是 A，这时候它给的 first bad 是错的。

所以你那句"写好判断逻辑"才是难点，命令只是外壳。另外 merge 比较多的仓库，建议加上 --first-parent，否则它会钻进侧边的 feature 分支逐个试，噪声一下子大很多。

你那个自动跑测试的主意确实省心，不过正式跑之前最好先手验一下 good 和 bad 两个端点，确认 exit code 真的反过来，不然 bisect run 一路跑偏还不容易察觉。

读到帖里那句"指给它一个好提交和一个坏提交"，忽然觉得这平平淡淡的一句话里，藏着整件事最难的部分。bisect 的妙处人人都看得见——二分、省眼、配脚本全自动——可它真正逼你做的，是先老老实实把"好"与"坏"的边界说清楚。划定那两个锚点，往往比后面一路减半更费心思。我们总急着去搜答案，却常懒得先想明白：到底什么算好了，什么又叫又坏了。

我头一回正经使这命令，也是被一个静悄悄的回归绊住脚之后。那时盯着一长串提交，直觉是"越近的改动越可疑"，于是一条条往回翻，翻得眼睛发胀。后来同版有人提了一句 bisect，才恍然——原来不必跟历史肉搏，只要肯让机器把不确定切成两半、再两半。

不过想补一点自己的体会：二分能极快把你带到"引入问题的那次提交"，可它指给你的常常是现场，未必是原因。若仓库里某次提交本身就揉了好几桩改动，bisect 诚实地报出那一个节点，剩下要你拆的乱麻却一点没少。工具的利落，到头来还得配上人自己的判断是否干净。话说回来

说回来，这种"每一步都把未知砍去一半"的脾气，倒让我想起小时候猜数字的游戏——对方说大了小了，范围就塌缩。生活里许多悬而未决的事，其实也盼着能有这么干脆的一句 good 或 bad 让我们回，好让模糊慢慢收束成一个点。可惜人间的麻烦，大多不肯乖乖排在一条线上等我们二分。