git bisect 是唯一能系统性、可复现地定位引入 Bug 的具体提交的手段；它通过二分法将问题范围从数百次提交压缩至一次确认，需先用 git bisect start 初始化，再用 git bisect bad 和 git bisect good 标记锚点提交。
git bisect 是唯一能系统性、可复现地定位引入 Bug 的具体提交的手段——它不靠猜，也不依赖模糊的日志描述，而是用二分法把问题范围从几百次提交压缩到一次确认。
怎么启动 git bisect 并标记好坏提交
启动前必须确保当前工作区干净（无未提交修改），且你手头有两个确定的锚点：good 提交（Bug 尚未出现）和 bad 提交（Bug 已存在）。通常 bad 就是当前 HEAD，good 可以是某个 release tag（如 v2.1.0）或已知稳定的 commit hash。
-
git bisect start：初始化二分状态 -
git bisect bad：默认标记当前 HEAD 为坏提交，也可显式写成git bisect bad HEAD -
git bisect good v2.1.0：用 tag 或 hash 标记好提交，Git 会立刻检出中间提交供你验证
注意：如果 good 和 bad 不在同一条线性路径上（比如跨了 merge commit），git bisect 可能跳过部分提交或给出误导性结果。优先选共祖提交更近的两个点。
手动验证时容易卡在哪几个环节
每次 git bisect 检出新提交后，你得快速判断这个版本是否“有 Bug”。这里最容易拖慢节奏或误判：
- 测试步骤不稳定：比如依赖本地环境变量、随机数、时间戳或第三方服务响应——会导致同一提交两次测试结果不同，
git bisect会陷入混乱 - 忽略构建失败：有些中间提交编译不过，但你没意识到，直接跳过或误标为
good；正确做法是运行git bisect skip，让 Git 自动绕开 - 验证标准模糊：例如“页面看起来不太对”，不如明确写成“调用
/api/users返回 500 状态码”或“测试用例test_login_fails_on_empty_password失败” - 忘记清理副作用：比如测试写入了临时文件或数据库脏数据，影响下一轮验证——建议每次验证前加一句
make clean或重置测试 DB
用 git bisect run 自动化验证的关键点
脚本自动化不是锦上添花，而是避免人为疲劳误判的核心环节。脚本必须满足三个硬性条件：
- 返回码严格：成功（无 Bug）必须 exit 0；失败（有 Bug）必须 exit 非 0（常用 1）
- 幂等可重入：多次执行不会累积状态，比如用
rm -rf node_modules && npm ci而不是npm install - 超时控制：加
timeout 60s防止某次构建卡死，否则git bisect run会中断
示例脚本 ./bisect-test.sh：
#!/bin/sh npm ci --no-audit > /dev/null && \ npm run build > /dev/null && \ curl -sf http://localhost:3000/api/health | grep -q "ok" || exit 1
然后执行：git bisect run ./bisect-test.sh。Git 会自动循环执行、标记、切换，直到输出最终 commit。
结束二分后别忘了清理状态
git bisect reset 不只是礼貌，而是必要操作——它会把你工作区切回原始分支（通常是 main 或 develop），并清除 .git/refs/bisect/ 下的临时引用。如果中途退出没重置，下次 git log 会看到奇怪的 detached HEAD 提示，甚至影响 push 行为。
真正容易被忽略的是：二分过程中所有 git bisect good/bad 的操作都被记录在 git bisect log 里，如果你需要回溯判断过程或分享排查路径，直接复制这条命令就能复现整个流程。
