汤不热吧在复杂的软件项目中，Bug 的发现往往滞后于其引入的时间。当一个 Bug 出现时，如果提交历史（Commit History）非常庞大，手动检查每一个 Commit 来确定是哪一次更改引入了问题，无疑是耗时且低效的。幸好，Git 提供了一个名为 git bisect 的强大工具，它利用二分查找法（Binary Search）的原理，能够指数级地加速这个定位过程。
什么是 Git Bisect？
git bisect 是 Git 内置的调试工具，旨在帮助你在提交历史中找出引入错误的第一个 Commit。它的工作原理是：在你指定的“已知好的版本”和“已知坏的版本”之间，反复地将历史记录一分为二，直到最终只剩下一个 Commit，即导致问题的那个 Commit。
如果你的项目有 $N$ 个 Commit，通过线性搜索需要 $O(N)$ 次检查；而使用 git bisect 只需要 $O(\log_2 N)$ 次。例如，有 1000 个 Commit，线性搜索可能需要 1000 次，而 git bisect 只需要大约 10 次检查。
实战演练：手动定位 Bug
假设你当前的代码分支存在一个 Bug，你确定这个 Bug 是最近才引入的，但在半年前的 v1.0 标签版本中，代码是正常的。
步骤一：启动二分查找
首先，你需要告诉 Git 你要开始二分查找过程。
git bisect start
步骤二：标记“坏”和“好”的边界
接下来，我们需要定义搜索范围：一个已知的“坏”版本（存在 Bug）和一个已知的“好”版本（没有 Bug）。
标记当前的 HEAD 为“坏”版本（假设 Bug 在此存在）：
git bisect bad
标记已知的“好”版本（例如，使用半年前的 v1.0 标签）：
git bisect good v1.0
Git 会根据这两个 Commit 自动跳转到中间的一个 Commit，并提示剩余需要检查的次数。
步骤三：测试与标记
现在，你需要在这个中间 Commit 上编译、运行代码并测试 Bug 是否仍然存在。
- 如果 Bug 仍然存在：说明在这个 Commit 或它之后引入了问题，这个 Commit 是新的“坏”边界。
git bisect bad - 如果 Bug 已经消失：说明引入问题的 Commit 在这个 Commit 之前，这个 Commit 是新的“好”边界。
git bisect good
Git 会自动将搜索范围再次减半，并跳转到下一个中间 Commit。你只需重复“测试”和“标记”的操作，直到搜索完成。
步骤四：查看结果并重置
当搜索范围缩小到只剩一个 Commit 时，git bisect 会输出结果，显示引入问题的那个 Commit 的哈希值和摘要信息。
# 示例输出
8f6b3e2a9b3d9d30d1e2e921d23b3203923a1a6b is the first bad commit
commit 8f6b3e2a9b3d9d30d1e2e921d23b3203923a1a6b
Author: Developer Name <dev@example.com>
Date: Mon Oct 23 10:00:00 2023 +0800
Fix: Update rendering logic to handle edge cases
定位完成后，无论你是否找到了 Bug，都应该退出 bisect 模式，将工作区恢复到开始前的状态（通常是 HEAD 所在的分支）。
git bisect reset
进阶技巧：自动化二分查找 (git bisect run)
如果你的 Bug 检查过程可以通过脚本自动化（例如，一个简单的测试用例返回 0 表示成功/Good，非 0 表示失败/Bad），你可以使用 git bisect run 来全自动地完成整个过程，无需手动干预。
假设你有一个名为 test_bug.sh 的脚本，当测试通过时退出代码为 0，失败时退出代码为 1。
# 启动自动化二分查找
git bisect start
git bisect bad # 当前 HEAD 有 Bug
git bisect good v1.0 # v1.0 是好的
git bisect run ./test_bug.sh
git bisect run 将会自动在每个检出的 Commit 上执行该脚本，并根据退出代码自动标记 good 或 bad，直到找到第一个引入 Bug 的 Commit。