Git bisect run 怎么用测试脚本自动找回归提交

当你知道 HEAD 已经出问题，而较早的 v1.8.0 仍然正常时，git bisect run 可以把“切换提交—运行测试—标记结果”串成自动循环。关键不在于把命令写得复杂，而在于测试脚本必须对每个提交给出稳定的退出码。

官方文档：https://git-scm.com/docs/git-bisect

步骤一：在 Git 客户端中标出正常与异常提交

打开仓库后，按 Repository > Bisect > Start。在 Bad revision 填入 HEAD，在 Good revision 填入 v1.8.0，确认状态栏显示 Working tree clean，点击 Start bisect。界面出现新的候选提交后，说明二分会话已经建立。

命令行等价写法如下。末尾的 -- 用来结束提交参数，避免后续路径参数被误解。

git bisect start HEAD v1.8.0 --  # 标记当前异常提交与已知正常提交
git status --short               # 确认没有未提交文件，避免测试结果被本地改动污染

步骤二：把可重复测试脚本交给 git bisect run

按 Bisect > Automation，在 Test script 选择仓库外的 ~/bin/bisect-check.sh，确认 Run command 为 git bisect run，点击 Run automation。脚本不要依赖某一次提交里才存在的文件，否则早期提交可能全部变成不可测试。

下面的脚本示例把构建环境不完整视为 skip，把测试失败视为 bad。脚本放在仓库外，可减少二分切换对脚本本身的影响。

#!/bin/sh
# 先判断当前提交是否具备可测试的 Go 模块环境
if [ ! -f go.mod ] || ! command -v go >/dev/null 2>&1; then
  exit 125  # 当前提交无法测试，交给 bisect 跳过
fi

# 只运行能稳定复现回归的窄测试，避免整套测试带来噪声
go test ./internal/codec -run '^TestDecodeRoundTrip$' -count=1
status=$?
if [ "$status" -eq 0 ]; then
  exit 0    # 测试通过，当前提交属于 good
fi
exit 1      # 测试失败，当前提交属于 bad

也可以直接执行：

git bisect run ~/bin/bisect-check.sh  # 让 Git 在每个候选提交上调用脚本

步骤三：查看首个坏提交并退出二分会话

当自动化结束，进入 Bisect > Result，点击 Open commit detail 查看 First bad commit。不要只记短哈希，最好连同提交主题和变更文件一起记录。点击 Reset to original HEAD 清理会话；如果需要保留判断过程，先导出 Bisect log。

git bisect log > bisect-log.txt  # 保存每轮 good、bad、skip 判断，方便复盘
git show --stat BISECT_HEAD      # 查看当前二分结果涉及的提交与文件范围
git bisect reset                 # 退出会话并回到开始二分前的提交

如果脚本频繁返回 125，结果只能说明候选范围里有许多提交无法验证；如果返回了 126 或 127，也要检查脚本权限与命令是否存在，不要把脚本错误误判成代码回归。

常见问题

测试脚本应该放在仓库里面吗？

不建议。放在仓库外可以避免 checkout 旧提交时覆盖脚本，路径和依赖也更稳定。

为什么不直接把编译失败标记为 bad？

只有编译失败由目标回归导致时才应标记 bad；如果是旧提交缺少依赖或环境不兼容，应返回 125 跳过。

二分结束后能否继续停留在首个坏提交？

可以先用 git show BISECT_HEAD 或结果面板查看它；确认记录完成后再执行 git bisect reset，恢复工作区。