- 约1294字
- 技术
- 2026年4月5日
90%的Bug不需要逐行看代码，靠Git就能定位。
这不是标题党，是我上周刚用完的真实经历。
上周二下午4点，测试同事突然在群里扔了一句：「线上有个订单创建失败的Bug，用户的订单直接没了，但后端没报错。」我的心咯噔一下——这种「悄悄丢失数据」的Bug最恐怖。
我赶紧拉了最近10次的部署记录，一个一个回滚测试。4点半、5点、5点半……整整两个小时，从最后一次发版开始，一个commit一个commit地往前倒。最后定位到下午3点15分的一个提交——有人改了个看似无关的字段校验逻辑。
如果当时我知道Git bisect，这两个小时可以变成3分钟。
什么是Git bisect
Git bisect是Git内置的二分查找工具。它的原理很简单：你告诉它一个「好的」提交和一个「坏的」提交，它会自动在历史中跳转，让你测试哪个提交引入了问题。每次测试只需要判断「当前版本有没有问题」，不用写代码、不用看日志，纯靠手动测试就能快速缩小范围。
理论上，1000个提交最多测试10次就能定位到具体是哪一个。
怎么用
最基础的用法就三步：
# 1. 开始二分查找
git bisect start
# 2. 标记当前版本是坏的（有Bug）
git bisect bad
# 3. 标记一个好的版本（确定没问题的提交）
git bisect good v1.0.0
执行完这三条命令，Git会自动跳转到中间的一个提交。现在你去测试功能，判断这个版本有没有问题：
# 这个版本有问题
git bisect bad
# 这个版本没问题
git bisect good
Git会继续跳转。循环这个过程，直到它输出类似这样的结果：
b1a2c3d is the first bad commit
commit b1a2c3d4e5f6g7h8i9j0
Author: someone <someone@example.com>
Date: Tue Apr 2 15:15:00 +0800
fix: add order validation logic
找到第一个坏提交后，记得用git bisect reset回到原来的位置。
进阶技巧
指定范围：如果知道大概的问题区间，可以直接指定起点和终点：
git bisect start --term-old=working --term-new=broken
git bisect working --since="2024-01-01"
git bisect broken HEAD~10
自动测试：如果有个测试脚本可以判断有没有Bug，可以让它自动跑：
git bisect start
git bisect bad HEAD
git bisect good v1.0.0
git bisect run npm test
脚本返回0算good，非0算bad，Git会自动跑完整个流程。
跳过无法测试的提交：有时候某个提交根本打不开项目，想跳过：
git bisect skip
什么场景不适合用
说清楚了，Git bisect不是万能的。
如果你的Bug表现是「新增功能不能用」，而不是「原有功能突然坏了」，二分查找帮不上忙。它适合的是「某天突然出现的问题」，你需要有一个可以对比的「没问题」的版本。
另外，如果你的项目每次提交都跑全套测试用例，那Bug应该在CI阶段就被拦截了，bisect的作用也不大。
真实的取舍
用了两周下来，我的体会是：它是那种「不知道时觉得没用，知道后天天用」的工具。
最大的成本是「心理门槛」——很多人(包括我)觉得git命令太专业，怕学不会。但实际上，这就是三个命令的事。真正省下来的是时间：以前要手动回滚、部署、测试，现在交给Git自动跑，测试几次就出结果。
唯一要注意的是：标记「好」和「坏」的提交时，要确保自己对状态判断准确。标记错了，整个排查结果都会偏。
小结
- Git bisect用二分查找快速定位问题提交
- 基础用法：start -> bad -> good -> 循环测试
- 进阶：指定范围、自动测试脚本、跳过不可测提交
- 适用场景：「原有功能突然坏了」，不适用「新增功能不能用」
下次遇到「明明没改代码，为什么突然出Bug」的情况，别再一个个commit回滚了。3分钟定位它。