如何用 git bisect 快速定位引入 Bug 的提交

在团队协作开发中，最令人头疼的场景之一莫过于：某个功能昨天还好好的，今天突然就坏了，而在这期间仓库里已经合并了几十个甚至上百个提交。面对这种情况，靠肉眼逐个 git log 翻看 diff 无异于大海捞针。好在 Git 提供了一个专门为此设计的利器——git bisect。它用二分查找的方式，帮助你在对数级的时间复杂度内锁定“肇事”提交。

为什么不用 git log 慢慢翻？

假设在 100 个提交中有一个引入了 Bug，线性排查最坏情况下需要检查 100 次。而二分查找每次都能将候选范围缩小一半，最多只需要约 7 次（log₂100 ≈ 6.64）就能定位到具体提交。提交越多，git bisect 的优势越明显。对于拥有上千次提交的大型项目，这种效率差距是数量级的。

核心思想：二分查找

git bisect 的原理非常朴素：你告诉它一个“好”的提交（已知没有 Bug）和一个“坏”的提交（已知存在 Bug），它会自动检出两者中间的某个提交，让你测试并标记为 good 或 bad。Git 根据你的反馈不断缩小范围，直到找到第一个“坏”提交——也就是引入 Bug 的那一次提交。

基本用法：手动模式

第一步：启动 bisect

git bisect start

第二步：标记坏提交和好提交

通常当前 HEAD 就是有 Bug 的版本：

git bisect bad

然后找到一个已知正常的提交。可以是某个标签、某个 commit hash，或者用相对引用：

git bisect good v2.3.0
# 或者
git bisect good HEAD~50

执行后 Git 会输出类似信息：

Bisecting: 24 revisions left to test after this (roughly 5 steps)
[abc1234] 重构用户认证模块

此时工作区已经自动切换到了中间那个提交。

第三步：反复测试并标记

对当前检出的版本进行测试。如果 Bug 存在：

git bisect bad

如果 Bug 不存在：

git bisect good

每次标记后，Git 都会自动检出新的中间提交，并告诉你还剩多少步。重复这个过程，直到 Git 输出类似：

abc1234 is the first bad commit
commit abc1234
Author: Zhang San
Date:   Mon Jan 15 10:23:45 2024

    重构用户认证模块

这就是引入 Bug 的提交。

第四步：结束 bisect

定位完成后，务必退出 bisect 状态，回到原来的分支：

git bisect reset

自动化模式：git bisect run

手动测试虽然直观，但如果每次都要编译、运行测试用例，反复操作也很繁琐。git bisect run 可以让你指定一个脚本，Git 自动执行该脚本并根据退出码判断好坏：

• 退出码 0：good
• 退出码 1-127（除 125 外）：bad
• 退出码 125：跳过当前提交（比如无法编译）

例如，你有一个测试脚本 test.sh，Bug 存在时返回非零：

git bisect start
git bisect bad HEAD
git bisect good v2.3.0
git bisect run ./test.sh

Git 会自动完成所有中间步骤，直接告诉你第一个坏提交。整个过程无需人工干预，特别适合 CI 环境或测试用例已经覆盖了 Bug 场景的情况。

实用技巧与注意事项

1. 跳过无法测试的提交

有时候中间某个提交因为依赖问题或编译错误无法测试，可以用：

git bisect skip

Git 会尝试选择另一个提交。如果跳过的提交太多，最终可能只能给出一个大致范围。

2. 查看当前进度

git bisect log

这会输出到目前为止的所有标记记录，方便你保存或分享。

3. 可视化辅助

git bisect visualize

它会打开 gitk 或类似的图形工具，直观展示当前剩余的候选提交范围。

4. 处理合并提交

如果 Bug 是在某次合并中引入的，git bisect 默认会检查合并提交本身。你可以通过 git bisect good/bad 正常标记，Git 会正确处理。如果只想在线性历史上查找，可以使用 --first-parent 选项：

git bisect start --first-parent

5. 恢复之前的 bisect 会话

如果你不小心中断了 bisect，可以用以下命令恢复：

git bisect replay bisect_log.txt

前提是你之前用 git bisect log > bisect_log.txt 保存过记录。

一个真实场景示例

假设你发现线上版本有一个严重的登录 Bug，而两周前的发布是正常的。你可以这样做：

# 确认当前版本有问题
git bisect start
git bisect bad

# 两周前的标签是正常的
git bisect good v1.8.0

# 假设每次测试需要运行单元测试
git bisect run npm test

几分钟后，Git 就会精确指出是哪个提交破坏了登录逻辑。接下来你就可以针对性地修复或回滚。

总结

git bisect 是每个开发者都应该掌握的基本技能。它把“在大量提交中找 Bug”这个看似困难的问题，转化为几次简单的测试和标记。无论是手动模式还是 git bisect run 自动化模式，都能显著缩短定位问题的时间。下次再遇到“昨天还好好的”这类问题时，不妨先试试 git bisect，而不是一头扎进 git log 的海洋里。

未经允许不得转载：任鹏个人博客 » 如何用 git bisect 快速定位引入 Bug 的提交