趣话题：git三部曲（一）-bug之争，到底谁才是该背锅的那个人？

前言

作为程序员，在职场当中经常遇到出现了问题需要定职定责的情况。比如某个系统出现了bug，导致了故障，那么这口锅究竟是谁的？这个是需要讨论的，一般来说需要测试、开发一起来背锅。如果代码不是我们写的，我们肯定是不想背这个锅的，那么怎么样来证明出bug地方的代码是谁写的呢？

这个时候我们就可以使用git来寻找代码的提交记录，从而找到罪魁祸首。

追查记录

Git当中有一个很重要的功能叫做git blame，从名字我们就可以看出来，这个功能是用来甩锅的。我们可以通过它查找到每一个文件每一行的提交记录，究竟这行代码是谁修改和引入的，非常方便我们用来定责。

Git blame可以传入一个参数L指定某一个文件的行数，比如我随便找了一个我private的repo运行了一下：


git blame -L 23,30 myhive.py

这里的23,30表示的myhive.py这个文件行数的起始位置，开始是第23行，结束是第30行。接着我们会进入到一个vim文件当中，给我们详细展示这些代码的情况。

我们可以看到结果分成4列，第一列是commit id，对应的是这一行代码是在哪一个commit当中出现的，第二列是提交人，也就是做出修改的人。第三列是修改时间，第四列是具体的代码内容。

当然由于这是我个人的repo，所以看到的代码都是我个人修改的。如果是大家一些协同开发的项目，就可以看到多人提交的情况了。

当然现在一些先进的IDE当中也集成了这个功能，比如著名的jetbrains全家桶，我们可以通过右键选择git，之后选择Annotate，之后代码左侧会展示对应的修改人以及修改时间，方便我们追查代码的修改对象。其实也不只是在问责，比如在阅读其他团队的代码的时候，遇到问题了，要找对应的人询问，也是一个很好的方法。

二分查找

我第一次看到这个功能的时候的确被惊艳了，但是回想起来至今好像也没用上过。可能在一些特定的场景下会有用吧。

有的时候我们的repo会非常巨大，会有很多的开发者，我们每次上线的时候会合并数十个提交。这就导致了一个问题，当我们上线测试的时候，如果发现了bug会很难排查，因为你不知道是哪一个提交带来的问题。这个时候一个比较好的办法当然是二分查找，当然我们也可以手动进行，然而git当中集成了这个功能，我们直接使用就好。

首先我们运行git bisect start，表示我们开始二分查找。bisect就是git当中二分查找的工具。

之后我们继续输入git bisect bad，表示当前的分支是有问题的。接着我们输入git bisect good xxxx，这里的xxxx是一个commitid或者是一个标签，告诉git我们最后一次已知的正确的提交是哪一个。这样git会把当前和这个提交之间的提交全部找出来，假如说这当中一共发生了23个提交，那么git会选出中间的提交进行跳转。

这个时候如果我们在这个中间的分支上测试OK，那么我们就输入git bisect good，告知git这个分支是正确的，从而帮助它缩小范围。如果这个分支错误，那么就输入git bisect bad。

当二分到最后git找到了那个最早出问题的提交之后，它会告诉我们提交的commitid以及相关的提交记录，这样可以方便我们更快地找到bug。

由于我没有很好的测试repo，所以只能找来一张截图，当我们找到错误的分支之后，git输出的结果是这样的，注意一下下方的提示语：

最后，不要忘了使用git bisect reset重置HEAD指针回到最开始的位置，否则可能会陷入一些奇怪的状况当中。

如果我们有健全的测试脚本可以测试提交是否正确的话，比如正确返回1否则返回0，我们也可以让git自动执行二分查找。比如这样：

git bisect start HEAD xxxx
git bisect run test_case.sh

这样git会调用test_case.sh这个文件，直到找出错误提交为止。其实还是挺方便的，只是我作为开发的时候很少接触这么多提交一起发布的状况，一般来说要处理的提交数量都很少，有bug也很容易找到。

最后的最后

送各位小伙伴一个好玩的学习教程吧，你可以根据自己需要选择订阅。
玩转Git分布式版本控制系统实战