Git bisect 怎么自动运行测试定位引入回归的提交

如果一个功能在某个版本还正常，升级后却回归，逐个提交手工测试很容易把“无法构建”误判成“功能坏了”。更稳的做法是先给出一个已知正常的 good 提交和一个已知异常的 bad 提交，再让 git bisect run 自动执行回归脚本。脚本用退出码告诉 Git 当前提交属于 good、bad，还是暂时不能测试。

真正的关键是让测试脚本只表达结论：退出码 0 表示正常，1 到 124 表示回归，125 表示当前提交不可测试。定位结束后执行 git bisect reset，工作区才会回到开始二分前的状态。

步骤一：先固定 good 和 bad 边界

打开 Git 工作台，进入菜单路径 Repository → Bisect → Start。在 Good commit 填写最后一个确认正常的提交，在 Bad commit 填写当前已经出现回归的提交，点击 Start bisect。如果使用命令行，等价操作如下：

# 把异常提交和正常提交交给 Git，建立二分会话
git bisect start HEAD stable-2026-01

# 也可以分开标记，便于确认每个边界的含义
git bisect bad HEAD
git bisect good stable-2026-01

Git 会切换到中间提交，并提示大约还剩多少次测试。这里的 good 不一定是某个版本标签，也可以是你已经通过回归测试的提交；重要的是它确实位于 bad 提交之前，并且目标问题在这两个边界之间发生。

图中的提交引用只是示例。实际操作时不要直接复制示例值，先用 git log --oneline 或仓库历史面板确认边界。

步骤二：把回归测试交给 git bisect run

进入 Repository → Bisect → Run Test，在 Test command 中填写 ./scripts/check-regression.sh。这个脚本必须能在每个被检出的提交上独立运行：先准备依赖和测试数据，再执行目标测试，最后把测试结果转换成退出码。

#!/usr/bin/env bash
set -u

# 构建失败通常是该提交无法测试，不要直接当成回归
if ! go test ./internal/regression; then
  # 这里的 125 会让 git bisect run 跳过当前提交
  exit 125
fi

# 测试通过返回 0，断言失败返回 1
if go test ./internal/regression -run TestLegacyResponse; then
  exit 0
else
  exit 1
fi

保存脚本并赋予执行权限后，在仓库根目录运行：

# 确保脚本可执行，再让 Git 自动循环测试
chmod +x ./scripts/check-regression.sh
git bisect run ./scripts/check-regression.sh

退出码映射要保持稳定：0 表示 good，1–124 或 126–127 表示 bad，125 专门表示无法测试；脚本返回其他值时，二分会中止。脚本不要输出带颜色的复杂文本来代替退出码，日志可以帮助排查，但不能代替结论。

步骤三：遇到无法构建的提交就跳过

在 Repository → Bisect → Skip Current 中可以手动跳过当前提交，命令行对应 git bisect skip。自动脚本遇到缺失依赖、生成文件缺失或与目标回归无关的构建错误时，应返回 125，让 Git 自动记录该提交不可测试。

# 手工跳过当前检出的提交
git bisect skip

# 查看当前已经标记过的二分记录
git bisect log

# 查看仍待测试的候选提交
git bisect visualize

跳过会缩小可用信息量。如果首个坏提交恰好挨着被跳过的提交，Git 可能只能告诉你一个范围，而不是唯一的提交。因此，脚本应该尽量把“环境准备失败”和“功能断言失败”区分开，并在日志中保存失败原因。

步骤四：记录结果并安全回到原分支

二分结束后，Git 会报告首个坏提交候选。先在 Repository → Bisect → Result 中复制提交号，再查看该提交的改动和测试日志，确认它确实改变了目标行为。不要在 bisect 状态下继续开发或直接提交修复。

# 查看二分过程，确认 good、bad 与 skip 记录
git bisect log

# 查看 Git 认为的首个坏提交详情
git show --stat bisect/bad

# 清理二分状态，默认回到启动前的 HEAD
git bisect reset

如果想停留在当前定位到的提交，可以使用 git bisect reset HEAD；如果需要回到首个坏提交再检查，也可以使用 git bisect reset bisect/bad。收尾后再运行 git status，确认没有残留的 bisect 状态或测试脚本临时改动。

常见问题与边界

测试脚本需要输出 good 或 bad 吗？

不需要。git bisect run 主要读取退出码，标准输出只用于辅助诊断；把结论固定为退出码，脚本更容易在 CI 或不同提交之间重复运行。

为什么 125 不能表示测试失败？

Git 把 125 约定为“当前版本无法测试”，因此会执行跳过逻辑。真正的回归断言失败应使用 1 到 124，避免把坏提交从搜索空间中误删。

收尾检查

一轮可靠的自动二分应该满足三点：good/bad 边界可解释，脚本在每个提交上只用退出码给出结论，无法测试的提交明确返回 125。定位后执行 git bisect reset，再回到正常分支流程，最后用一次独立回归测试验证结论。