Git bisect 定位回归：先写可靠判定，再缩小提交范围
功能在旧版本正常、当前版本失败，逐个浏览提交记录很费力。Git bisect 可以利用已知的正常与异常边界，逐步缩小引入变化的范围。但它的可靠程度取决于测试判定：如果网络抖动、依赖漂移或环境残留会改变结果，再聪明的搜索也可能指向错误提交。本文使用 Git 2.x 常见命令，操作应在可用于测试的干净工作目录中进行。
AI生成概念配图：在正常与异常提交之间逐步缩小可疑区间。仅辅助理解，不代表真实界面或实测结果。
先验证两个端点
准备一个尽量小的复现步骤，明确输入、预期结果和失败表现，然后分别在已知正常版本与异常版本运行。两个版本应采用可比较的运行条件。外部接口返回变化、当前时间或随机数会影响测试时，应先控制这些变量；无法稳定区分端点，就还不适合开始二分。
git --version git status --short # 将 BAD_REF 和 GOOD_REF 换成实际提交或标签 git bisect start BAD_REF GOOD_REF
开始前提交或另行保存需要保留的修改，并确认未跟踪与忽略文件中没有会被测试覆盖的重要内容。bisect 会在历史提交间切换，构建脚本也可能改写产物或运行迁移，因此不要在生产目录里进行。旧版本程序同样可能有漏洞，测试环境不应携带生产凭据或连接真实业务服务。
每一轮只回答实际观察到的结果
# 当前检出的版本通过复现测试 git bisect good # 或者，当前版本出现同一目标故障 git bisect bad # 当前版本确实无法测试时 git bisect skip
上面三项是不同情况的备选命令，不能依次全部执行。构建不通过未必就是要追踪的业务回归；如果属于独立的环境不兼容，应记录原因并考虑 skip。跳过关键边界附近的提交，可能使 Git 最后只能给出一组候选而非唯一答案，这时需要补充测试条件，不能硬选其中一个。
自动化之前先定义退出码契约
git bisect run 把退出码零解释为正常，将一到一百二十七中的大多数非零值解释为异常，一百二十五专用于跳过；超出这个范围会使自动过程停止。命令不存在或不可执行的错误若未经处理，也可能被误判成异常版本，所以包装脚本必须把测试失败与基础设施失败区分开。
#!/usr/bin/env bash # 这两个脚本须在目标项目中自行实现并事先验证 if ! ./build-for-test.sh; then exit 125 fi ./check-regression.sh rc=$? case "$rc" in 0) exit 0 ;; 1) exit 1 ;; *) exit 128 ;; esac
示例约定检查脚本仅用零表示通过、一表示目标回归，其他结果表示无法信任本轮测试并停止搜索。构建失败在这里被当作不可测试而跳过；如果你追踪的恰好是构建回归，就必须改变这一策略。包装脚本最好放在检出目录之外，避免历史版本切换时将它覆盖，并固定需要的工具链。
git bisect run bash /absolute/path/bisect-check.sh git bisect log > ../bisect-session.log git bisect reset
找到候选以后，还差一次因果验证
保存二分日志，再检查候选提交及其相关父提交，重复运行相同复现用例。必要时在隔离分支中验证撤销或最小修复是否改变结果。bisect 找到的是在给定历史与判定下的边界，并不自动解释根因；提交间交互、故障反复出现或测试不稳定，都可能破坏直觉上的单调假设。
最终报告应包括正常与异常起点、复现脚本版本、环境、跳过记录、候选提交和复查结果。这样同事可以重复结论，而不是只收到一个缺少证据的提交号。结束后用 reset 返回开始前的位置，并另行处理测试产生的文件，避免把临时调试状态留给下一项工作。
