用历史定位一次真实错误
项目发布后出现问题：任务数量上限可以变成 0 或负数。我们会先用搜索命令回答“相关内容在哪里、何时改变、谁最后修改”，再让 git bisect 自动找出第一个坏提交。
准备可自动判断的检查脚本
先给项目增加有效配置：
bash
mkdir -p scripts
printf 'max_tasks=10\n' > settings.conf创建 scripts/check-settings.sh：
bash
#!/bin/sh
value=$(sed -n 's/^max_tasks=//p' settings.conf)
test "$value" -ge 1赋予执行权限并提交：
bash
chmod +x scripts/check-settings.sh
git add settings.conf scripts/check-settings.sh
git commit -m "feat: add positive task limit"立即运行检查：
bash
./scripts/check-settings.sh
printf '退出码：%s\n' "$?"结果：
text
退出码：0程序退出码 0 表示检查通过，非零表示失败。这个约定让 git bisect run 能自动判断每个历史版本的好坏。
记下当前好提交：
bash
git log --oneline -1结果示例：
text
2d6a3e2 feat: add positive task limit制造一段包含错误的历史
依次创建三条配置变化：
bash
printf 'max_tasks=20\n' > settings.conf
git commit -am "feat: raise task limit"
printf 'max_tasks=0\n' > settings.conf
git commit -am "refactor: allow unlimited tasks"
printf 'max_tasks=-1\n' > settings.conf
git commit -am "chore: tune task limit"当前检查失败：
bash
./scripts/check-settings.sh
printf '退出码：%s\n' "$?"结果为 退出码：1。我们知道最新版本坏了，也知道 2d6a3e2 是好版本，但暂时不直接查看中间提交来判断答案。
在当前文件中搜索
git grep 只搜索 Git 管理的文件，适合快速定位项目里的词语：
bash
git grep -n "负责人"结果：
text
README.md:11:可按负责人查看任务。
tasks.md:1:负责人：小林、小周
tasks.md:11:- [ ] 按负责人筛选也可以指定历史版本：
bash
git grep -n "负责人" v1.0.0这样可以在不切换分支的情况下检查发布版本中的内容。
搜索变化何时进入历史
git log -S 查找“某个字符串出现次数发生变化”的提交：
bash
git log -S"负责人" --oneline结果示例：
text
b9ce389 feat: document task filters
6457dcd chore: initialize team task board查看某条结果的补丁：
bash
git show b9ce389如果要用正则匹配补丁中的变化，使用 git log -G'正则'。简单记忆：-S 关注字符串数量变化，-G 关注补丁行是否匹配正则。
针对当前配置，可以直接搜索：
bash
git log -S'max_tasks=0' --oneline -- settings.conf这通常已经能找到可疑提交，但我们仍会用自动检查确认“第一个坏提交”，避免只凭提交信息猜测。
查看每一行最后由谁修改
bash
git blame -L 1,1 tasks.md结果示例：
text
bc6bde7b (小林 2026-07-15 02:49:02 +0000 1) 负责人：小林、小周blame 提供提交、作者、时间和行内容。它的用途是找到上下文，不是寻找“应该负责的人”。拿到提交 ID 后继续执行 git show bc6bde7b，才能理解那次修改的完整原因。
重命名、代码移动和大规模格式化会影响逐行归属。需要时可以尝试 git blame -M -C 文件，但最终仍要阅读提交补丁和相关讨论。
用 bisect 二分定位首个坏提交
启动二分过程，并标记当前版本为坏：
bash
git bisect start
git bisect bad HEAD把前面记下的有效配置提交标为好：
bash
git bisect good 2d6a3e2Git 会检出好坏之间的中间提交。手动方式是每次运行检查，再执行 git bisect good 或 git bisect bad。我们已经有脚本，可以自动完成：
bash
git bisect run ./scripts/check-settings.sh关键结果示例：
text
f5bae607db25dad333d5dc5af175add0fa177132 is the first bad commit
commit f5bae607db25dad333d5dc5af175add0fa177132
Author: 小林 <xiaolin@example.com>
refactor: allow unlimited tasks
settings.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
bisect found first bad commitGit 用两次脚本运行在候选范围中找到了第一条失败提交。提交 ID 会因你的历史而不同，但提交信息应是 refactor: allow unlimited tasks。
结束二分并回到开始时的分支：
bash
git bisect reset不要漏掉这一步。二分期间 HEAD 会暂时停在历史提交上，reset 子命令负责恢复原位置。
从线索到结论
这次排错遵循一条可复用路线：
先稳定复现问题，并把“正确或错误”变成退出码明确的检查脚本。
用 git grep 找当前内容，用 git log -S 或 -G 缩小历史范围，用 git blame 找到行级上下文。
给 bisect 一个确定的好提交和坏提交，让它用二分法选择候选版本。
用 git bisect run 自动检查候选提交，得到首个坏提交后阅读完整补丁，最后执行 。
下一节会把 max_tasks 修复为正数，检查 Git 对象是否完整，创建 v1.1.0，再从标签克隆一个全新副本完成验收。
1
git bisect 至少需要哪两个边界？
2
git blame 的主要用途是给错误分配责任。