Write More Bits

bisect和blame，两个命令一般都是在出现bug的时候使用。

• git bisect (hg, svn支持)

  发现本来挺好的程序，合并别人的修改之后，居然出现了bug，这个时候，我们有两种方法去除bug：

  1. 调试最终程序，尝试直接找到问题所在。

     如果是程序崩溃、空指针等这些明显问题，还好办，如果是复杂逻辑问题，那得花费大量时间了…

  2. 在合并来的多个commit中，逐个搜索，找到出引入bug的commit，之后通过commit的修改内容定位bug代码

     这样子，将问题定位到一个commit，可以从commit的修改本身着手，从而能够很大程度上简化bug查找过程

  如何定位来自对方的哪个commit造成了bug？(当然，bug可能在对方的代码中并不存在，是合并后代码共同作用的结果。)如何找出是哪个commit造成的合并结果，也是同样麻烦。
  学计算机的人都知道二分搜索，加快查找速度，git bisect做的正是此事。(注意这个命令的名字，非常贴切: bisect=BInary SEarch CommiT)通过使用bisect start 设置好二分的界限，之后bisect将本地代码的状态滚动到中间的某个commit，之后，我们验证当前代码库是否有bug存在，使用bisect good/bad标志当前commit。bisect接收到指令之后，会继续在剩下的区间进行二分查找。
  这命令我本身也没有使用过，第一见到其描述是在《Beautiful Code》中的一章，之后在git、hg和svn中都发现了类似的东西。感觉在处理较大规模、开发并行度较高、提交比较频繁的项目中，处理bug，可能有用。

• git blame (hg, svn支持)

  当你明确知道某个bug来自某行代码的时候，想知道这行代码是谁写的，然后找到该人去泄愤一下，blame正是泄愤证据的最有利提供者。blame明确输出，某行代码是某人在某个commit中写的。这命令名字取的非常到位，找到谁是可以blame的人，哈哈

Filed under:
scm by Yang Bo