前言
介绍了 Git bisect 工具的使用方法，通过指定一个范围找到造成 bug 的 commit，并使用二分搜索法快速定位。作者演示了手动和自动测试的方法，使定位 buggy commit 更加高效。最后提醒了保持 commit 精简，以便更轻松地使用 Git bisect 找出 buggy commit。今日前端早读课文章由 @Larry Lu 分享。
正文从这开始～～
Git 作为近年来最流行的版本控制工具，除了提供基本的 add、commit、push 功能之外，其实还有很多进阶的指令可以用～这次要介绍的 Git bisect 我都觉得非常好用，可以说是必学的 Git 指令！
前情提要
有用过 Git 进行多人协作的话应该都知道：通常在团队中开发或是参与开源项目时，每个人都会开自己的 feature branch，直到功能完成之后才 merge 回主线
不过团队成员多了之后，不只开出去的 branch 多了，主线上也会不断有新完成的 branch 合并进来。导致有一天在主线上发现 bug 时，那个 bug 可能也存在一阵子了（也许几十个 commit 之前）
但因为每天都有一堆 branch 合并回主线，而且每个人都说「在我那个 branch 没这问题啊」，所以想找出主线上的 bug 到底是哪个 commit 造成的非常费工
那在这种情况下，究竟要怎么在茫茫 commit 海中找出 buggy commit 呢？这时就要把 Git Bisect 请出来了
Git bisect
Git bisect 的原理是这样的：虽然你不知道 buggy commit 是哪一个，但你可以指定一个范围叫 Git 帮你找 buggy commit（范围多大都没问题）
接着 Git 就会在范围内使用二分搜寻法跳来跳去（所以才叫 bi sect），如果你告诉 Git 这个时间点已经有 bug 了他就往旧的 commit 跳，若是 bug 还没发生则往新的 commit 跳，就这样直到揪出谁是 buggy commit
以上图来说，在选定了搜寻范围之后（一定要好坏各一），Git 第一步就会直接跳到中间的 commit 让你测试这个 commit 是好是坏
如果是坏的话，代表 buggy commit 一定在这个 commit 的左边，所以第二步往左跳了两个 commit 让你测试。如果这时测出来是 Good，那就会再往右跳一格，就这样不断的测试直到找到 Good 跟 Bad 的分界点，真的跟二分搜寻法一样对吧～
正因为是用二分搜寻法，可能的范围会不断切半切半再切半，所以即便是要在 1000 个 commit 里寻找 buggy commit，也只需要十次的测试就够了（2¹⁰ = 1024），可说是非常高效率
实际操作
身为工程师当然不能光说不练，所以这边要来实际操作一下，想跟着玩的话我也建了一个 repo。专案的历史纪录长这样，虽然只有七个 commit 有点闹 XD，不过意思有到就好了
给大家看一下，在最旧的 commit3e11686 上执行 node index.js 时结果是 Hello World，但到了最新的 commit0767776 再执行 node index.js 则是出现 Hello Bug，代表这中间一定有某个 commit 把程式码改坏了
所以我们就启动 git bisect，并且把最新的 commit 标示为 Bad、最旧的标示为 Good，然后 Git 就会自动跳到中间的 commit 让我们测试（看 HEAD）
因为测试完之后发现结果还是 Hello Bug，所以就下 git bisect bad 告诉 Git 中间这个 commit 也是坏掉的，那 Git 就会继续帮你跳到需要测试的地方
就这样经过几次测试之后，Git 就会告诉我们是从 Minor bug fix 这个 commit 开始坏掉的，换句话说他就是 buggy commit，然后就可以下 git bisect reset 结束 git bisect，就这么简单～
有办法自动测试吗？
不知道各位有没有发现，说穿了 Git bisect 就是自动帮你切换到各个 commit 让你手动测试而已。但因为测试的步骤基本上都一样，像这个例子就是跑 node index.js 然后检查输出，所以当然也可以写成脚本让他自动化
【第2934期】利用好 git bisect 这把利器，帮助你快速定位疑难 bug
譬如说我要写个脚本要判断目前的 commit 是不是有 bug，那就先执行 node index.js，然后用 grep 判断他的输出有没有 World 就好了（正常应该要输出 Hello World）
如果有 World 就代表这个 commit 是 Good，所以就正常结束；没有的话则是代表这个 commit 是 Bad，用来代表异常，很简单吧～ exit 0Worldexit 1
if node index.js | grep World; then
exit 0
else
exit 1
fi
有了脚本之后就跟先前一样先选定要做 git bisect 的范围（从 3e11686 到 0767776）
设定好范围后马上就下 git bisect run ./test.sh 告诉 Git 要用刚写好的 test.sh 来判断 commit 的好坏，接着 Git 就会霹哩啪拉的跳来跳去，然后根据脚本的执行结果去标示 Good 跟 Bad，最后指出有问题的 commit 就是 Minor bug fix，跟之前手动测试的结果相同
因为已经把判断好坏的步骤都写到脚本里头了，所以放着跑一下就能找到 buggy commit，也不用再手动操作什么，真的很方便对吧！
总结
关于 git bisect 的介绍就讲到这边～希望大家下次找不到 bug 躲在哪个 commit 时都可以试试看 git bisect，真的会一试成主顾。不过前提是你的 commit 不能太肥，不然就算找到了 buggy commit，结果那个 commit 总共修改了两千行程式码，那大概连佛祖都帮不了你 XD
关于本文
作者：@Larry Lu
原文：https://medium.com/starbugs/use-git-bisect-to-find-the-buggy-commit-b35e12ddd26b
这期前端早读课
对你有帮助，帮” 赞 “一下，
期待下一期，帮” 在看” 一下 。
