“昨天还能用，今天就坏了。”在任何活跃的软件项目中，回归错误都必然会出现。从数百或数千个提交中查找引入错误的确切提交就像大海捞针一样。
您可以使用 Git 的内置调试工具：git bisect，而不是手动一一检查提交或花费数小时分析代码更改。
在本文中，我们将解释如何使用 git bisect 的二分搜索算法在几分钟内找到错误的根源。
1. git bisect 的工作原理（二分查找）
git bisect 命令使用 二分搜索 算法来导航您的 git 历史记录。
假设您有 100 次提交，并且您知道该错误是在两者之间的某个位置引入的：
- Git 在中间签出提交（提交 #50）。
- 此时您可以测试应用程序。
- 如果代码被破坏，则该错误是在前半部分引入的（提交 1-49）。
- 如果代码有效，则该错误是在后半部分引入的（提交 51-100）。
- Git 再次将剩余范围一分为二（提交 #25 或 #75）并签出该版本。
通过重复这个过程，Git 成倍地减少了搜索空间。在 100 个提交中查找错误最多需要 7 个步骤，在 1,000 个提交中查找错误最多需要 10 个步骤 ($log_2(N)$)。
2. 分步手动指南
让我们逐步完成识别错误的手动过程。
第 1 步：启动二等分向导
启动二等分过程：
git bisect start
第二步：设定界限
将当前状态（有错误）标记为“bad”：
git bisect bad
接下来，确定该功能完美运行的过去版本（提交哈希或发布标签，如 v1.2.0），并将其标记为“良好”：
git bisect good a1b2c3d
Git 将立即检查该范围中点的提交。
第 3 步：测试和标记
运行您的应用程序或检查您的功能。
- 如果错误存在：
git bisect bad - 如果错误不存在（功能正常）：
git bisect good
每次输入标志时，Git 都会检查下一个候选测试。
第四步：找到罪魁祸首
一旦搜索空间缩小到单个提交，Git 就会输出最终结果：
e5f6g7h8i9j0a1b2c3d4 is the first bad commit
commit e5f6g7h8i9j0a1b2c3d4
Author: Jane Doe <[email protected]>
date: Mon Oct 15 12:00:00 2025 +0900
fix: change payment calculations
:040000 040000 8c1b2d3... 9e3f4a1... M src
您现在确切地知道哪个提交导致了回归！完成后，退出二等分模式以使存储库返回到其原始状态：
git bisect reset
3. 自动搜索 (git bisect run)
如果您的错误可以通过自动化脚本或测试命令（例如集成或单元测试）捕获，那么您可以自动化整个二等分运行。
git bisect start
git bisect bad
git bisect good v1.2.0
# Automatically run the test runner on every checkout step
git bisect run npm test
Git 会自动检查、测试和标记每个步骤，在几秒钟内完成搜索。
结论
下次遇到回归错误时，请抵制逐行调试的冲动。反而：
- 定义已知的好点和坏点。
- 启动
git bisect。 - 使用二分搜索缩小可疑提交的范围（或通过
git bisect run自动执行）。
它是一个强大的工具，可以添加到您的调试工具包中。