如果能写一个返回 0/非 0 的检查命令，git bisect 可以自动跑完整个二分过程，不用每次手动判断。环境：Git 2.25+，仓库里需要有一个能复现问题的脚本。
例如测试脚本 check.sh：
#!/usr/bin/env bash
set -e
./tests/smoke.sh
给它执行权限后，在已知正常和异常的提交之间运行：
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run ./check.sh
git bisect reset
脚本返回 0 会被当作 good，非 0 会被当作 bad，最后 Git 会指出首次出问题的提交。检查命令最好只依赖仓库本身，别把网络请求或不稳定的外部服务放进去，不然二分结果会飘。
补一个容易踩的点：脚本遇到当前提交无法判断时，可以返回 125，让 git bisect run 跳过这个提交，而不是把它误判成 bad。比如依赖文件缺失、构建条件不满足时先判断并 exit 125，最后的定位会稳一些。
Ryan小满Lv1#2 还有个实践上的细节：检查脚本最好把“测试失败”和“当前提交无法构建”分开处理，前者返回非 0，后者返回 125，别让依赖缺失把坏提交位置带偏。脚本如果会生成文件或改工作区，也要在每轮结束时清理，否则下一次 bisect 可能被上一次残留状态影响。
还有个方便复盘的用法：跑完后可以先把过程保存下来，之后在另一份工作区重放。
git bisect log > bisect.log
git bisect reset
# 需要复现时
git bisect replay bisect.log
这样测试脚本调整过，或者怀疑环境影响结果时，不用手动重新输入 good/bad 边界。日志里如果包含仓库路径或提交信息，分享前也扫一眼。