git bisect 能快速定位问题提交是因为采用二分法自动缩小范围，时间复杂度仅 o(log n)，前提是能稳定复现 bug 并明确 good/bad 提交，且验证过程需自动化、可重复。
git bisect 为什么能快速定位问题提交
因为它是用二分法在提交历史里自动缩小范围，把 git log 手动翻几十页的工作压缩到最多 O(log n) 次验证。前提是：你能稳定复现 Bug，且知道一个“好”的提交（没 Bug）和一个“坏”的提交（有 Bug）。
它不关心代码逻辑，只依赖你每次告诉它当前 HEAD 是 good 还是 bad —— 所以关键不是“怎么写代码”，而是“怎么定义好坏”。
- 必须先确保测试可自动化：哪怕只是跑一条
curl或执行一个python test.py，手动点界面基本没法用git bisect - 不能跳过编译失败的提交：如果中间某次
checkout后连make都过不了，得用git bisect skip，否则流程会卡住 -
git bisect默认按时间倒序选中点，但如果你指定了--first-parent，它会忽略 merge 提交的第二父节点，适合主干开发模型
怎么启动并推进一次 bisect 流程
从当前疑似有问题的提交开始，标记为 bad；再找一个已知没问题的历史提交（比如上个 release tag），标记为 good；之后让 Git 自动切到中间点，你来验证。
git bisect start git bisect bad git bisect good v1.2.0
Git 切换后，你只需运行验证逻辑（比如启动服务 + 发请求），然后根据结果执行：
- 如果 Bug 复现了 →
git bisect bad - 如果一切正常 →
git bisect good - 如果编译失败 / 无法运行 →
git bisect skip（可连续跳过多个） - 中途想退出？直接
git bisect reset，它会自动切回原始分支
遇到 merge 提交时为什么 bisect 会“绕远路”
默认情况下，git bisect 把 merge 提交当成普通节点处理，但它有两个父提交，Git 不知道该往哪边走，容易选错方向，导致多试几次，甚至漏掉真正引入 Bug 的那个父链。
如果你的项目是“主干开发 + 定期 merge feature 分支”，推荐加 --first-parent：
git bisect start --first-parent
- 这样 Git 只沿主干（第一个父提交）往前找，忽略 merge 进来的分支变更，更符合实际发布路径
- 但代价是：如果 Bug 真是某个被 merge 进来的提交引入的，而那个提交不在 first-parent 链上，就会被跳过 —— 此时得去掉
--first-parent重试 - 可以用
git show --pretty=%p -q HEAD快速看当前提交有几个父提交，判断是否 merge
脚本化 bisect 能省掉多少人工操作
把验证逻辑写成返回 0（good）或非 0（bad）的 shell 脚本，就能让 git bisect run 全自动跑完，不用你一次次敲命令。
例如验证 HTTP 接口是否返回 500：
#!/bin/sh
make build && ./server &
sleep 2
if curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/api | grep -q "500"; then
kill %1
exit 1
else
kill %1
exit 0
fi
- 保存为
test.sh，加上可执行权限：chmod +x test.sh - 然后运行：
git bisect run ./test.sh - 注意：脚本里所有路径、端口、依赖都要能独立运行，不能依赖当前终端环境变量
- 如果某次运行超时或挂起，
git bisect run会把它当bad，所以务必加超时控制（比如timeout 10s curl ...）
最常被忽略的是：脚本里启动的服务没清理干净，导致下一轮 curl 打到旧进程，结果误判。每次验证前后都该显式 kill 或用随机端口避免冲突。
