Git Bisect 自动定位器

它解决什么问题

当仓库规模变大后，一次看似普通的改动可能让 CI 或测试从绿色变红。若历史分支很长、提交密集，手工 git bisect 很容易陷入反复 checkout、手动跑测试、记录 good/bad 的循环。这个技能面向的是“需要尽快定位引入回归的提交”这个具体任务：把重复的判断流程交给可重复执行的脚本，而不是靠人肉翻提交日志。

技能如何工作

• 它以 git bisect 的二分语义为基础，调用 Git CLI 驱动 good / bad 标记。
• 测试目标可以来自自定义脚本，例如通过 git bisect run make 构建应用，或通过 git bisect run make test 构建并测试。
• 对构建失败的处理遵循 upstream 思路：用 make || exit 125 跳过损坏构建，避免把环境问题误判为逻辑回归。
• 面向 CI 场景时，它结合 GitHub Actions API 做流水线集成，把自动化二分与仓库的大型历史结合起来。
• 词法上可以按 Git 自身习惯使用 old / new 表述，而不是只能绑定 good / bad。

适用边界与注意点

• 前提是测试命令本身稳定：如果 make 或 make test 受缓存、外部服务、随机性影响，bisect 结果也会不稳定。
• 它依赖 Git 历史可达性；合并冲突、重写历史、稀疏检出等都会影响可二分性。
• CI 集成需要相应权限与网络可达性，权限不足时只能覆盖本地 Git CLI 部分。
• 根据 upstream 说明，流程不要求完整检出树；但若要使用 old / new，仍需按 Git 的方式发起 bisect。
• 它解决的是定位提交，不自动修复代码；找到可疑提交后仍需人工复核和回滚决策。