git bisect 是通过二分查找快速定位引入 bug 的提交；需先运行 git bisect start，再用 git bisect bad 和 git bisect good 标记已知坏/好提交，git 自动检出中间提交供验证。

用 git bisect 是最直接、最可靠的方式定位引入 bug 的提交，比手动翻 log 或逐个 checkout 快得多，且能自动二分收敛。

怎么启动 git bisect 并标记已知状态

先确保当前工作区干净（无未提交更改），然后运行：

git bisect start

接着标记一个「已知有问题」的提交（通常是当前 HEAD）和一个「已知没问题」的提交（比如上一个稳定 release）：

• 用 git bisect bad 标记坏提交（可省略参数，默认为 HEAD）
• 用 git bisect good v1.2.0 或 git bisect good abc1234 标记好提交

执行后 Git 会自动检出中间提交，等你验证。别跳过验证步骤——哪怕只是跑一次 npm test 或访问某个接口。

验证时遇到编译失败或测试不通过怎么办

git bisect 不关心具体错误类型，只依赖你返回的「好/坏」判断。常见干扰包括：

• 某次提交因依赖变更导致 yarn install 失败 → 这不是 bug 引入点，而是构建环境问题，应跳过：git bisect skip
• 测试用例本身在「好」分支里就偶尔 flaky → 需固定测试数据或加重试，否则误判会污染二分路径
• 被测功能在某个提交中被完全删掉 → 此时无法验证，也得 git bisect skip，Git 会调整搜索范围

跳过太多提交会导致结果不唯一，尽量往前找更稳定的 good 基线，比如 tag 而非 merge commit。

MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub

使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...

下载

如何自动化验证过程减少人工操作

用 git bisect run 可以把验证逻辑脚本化，例如：

git bisect run sh -c 'npm install && npm test'

只要命令返回 0（成功），Git 就认为是 good；返回 1–127（除 125）则视为 bad；返回 125 表示跳过。

• 脚本里记得清理临时文件，避免残留状态影响下一轮
• 如果测试耗时长，可在脚本开头加 timeout 60s 防卡死
• CI 环境中注意权限和缓存，node_modules 最好每次重新装

自动化虽快，但首次运行建议先手动走一遍，确认验证逻辑本身没缺陷。

退出 git bisect 后忘记恢复原始状态

结束之后必须执行 git bisect reset，否则 HEAD 仍停留在某个中间提交，后续 git pull 或 git checkout 都可能出人意料。

• 不带参数的 git bisect reset 会回到最初 git bisect start 前的位置
• 如果中途切过其他分支，reset 不会自动切回去，得自己 git checkout main
• 想保留 bisect 日志？查 git bisect log，但别依赖它做结论——日志里 skip 的提交可能掩盖真实根因

真正容易被忽略的是：有些 bug 表现依赖特定配置或数据，而 bisect 过程中你用的验证方式没覆盖到那个分支路径。这时候找到的「第一个坏提交」只是触发条件，不是根本原因。