Git笔记（34）调试

青旅半醒 2023-07-13 10:51 6阅读 0赞

### Git笔记（34） 调试 ###

*  1. 文件标注
 *  2. 二分查找

--------------------

# 1. 文件标注 #

如果在追踪代码中的一个 bug，并且想知道是什么时候以及为何会引入  
文件标注通常是最好用的工具  
它能 **显示任何文件中每行最后一次修改的提交记录**

所以，如果在代码中看到一个有 `bug` 的方法  
可以使用 `git blame` 标注这个文件，查看哪一次提交引入了这行

以下示例用 `git blame` 确定了 Linux 内核源码顶层的 `Makefile` 中每一行分别来自哪个提交和提交者  
此外用 `-L` 选项还可以将标注的输出限制为该文件中的第 69 行到第 82 行

$ git blame -L 69,82 Makefile
    b8b0618cf6fab (Cheng Renquan  2009-05-26 16:03:07 +0800 69) ifeq ("$(origin V)", "command line")
    b8b0618cf6fab (Cheng Renquan  2009-05-26 16:03:07 +0800 70)   KBUILD_VERBOSE = $(V)
    ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 71) endif
    ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 72) ifndef KBUILD_VERBOSE
    ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 73)   KBUILD_VERBOSE = 0
    ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 74) endif
    ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 75)
    066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 76) ifeq ($(KBUILD_VERBOSE),1)
    066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 77)   quiet =
    066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 78)   Q =
    066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 79) else
    066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 80)   quiet=quiet_
    066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 81)   Q = @
    066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 82) endif

请注意，第一个字段是最后一次修改该行的提交的部分 `SHA-1` 值  
接下来两个字段的值是从提交中提取出来的——**作者的名字以及提交的时间**  
所以就可以很轻易地知道是谁在什么时候修改了那一行

接下来就是行号和文件内容  
注意一下 `^1da177e4c3f4` 这个提交的几行  
其中的前缀 `^` 指出了该文件自第一次提交后从未修改的那些行

会带来小小的困惑  
因为目前至少已经看到三种 Git 使用 `^` 来修饰一个提交的 `SHA-1` 值的不同含义

另一件事情是 Git **不会显式地记录文件的重命名**  
它会记录快照，然后在事后尝试计算出重命名的动作  
这其中有一个特性就是可以让 Git 找出所有的代码移动

如果你在 `git blame` 后面加上一个 `-C`  
Git 会分析正在标注的文件， 并且尝试找出文件中从别的地方复制过来的代码片段的原始出处

比如，将 `GITServerHandler.m` 这个文件拆分为数个文件，其中一个文件是 `GITPackUpload.m`  
对 `GITPackUpload.m` 执行带 `-C` 参数的 `blame` 命令，就可以看到代码块的原始出处：

$ git blame -C -L 141,153 GITPackUpload.m
    f344f58d GITServerHandler.m (Scott 2009-01-04 141)
    f344f58d GITServerHandler.m (Scott 2009-01-04 142) - (void) gatherObjectShasFromC
    f344f58d GITServerHandler.m (Scott 2009-01-04 143) { 
    70befddd GITServerHandler.m (Scott 2009-03-22 144)         //NSLog(@"GATHER COMMI ad11ac80 GITPackUpload.m (Scott 2009-03-24 145) ad11ac80 GITPackUpload.m (Scott 2009-03-24 146) NSString *parentSha; ad11ac80 GITPackUpload.m (Scott 2009-03-24 147) GITCommit *commit = [g ad11ac80 GITPackUpload.m (Scott 2009-03-24 148) ad11ac80 GITPackUpload.m (Scott 2009-03-24 149) //NSLog(@"GATHER COMMI
    ad11ac80 GITPackUpload.m    (Scott 2009-03-24 150)
    56ef2caf GITServerHandler.m (Scott 2009-01-05 151)         if(commit) { 
    56ef2caf GITServerHandler.m (Scott 2009-01-05 152)                 [refDict setOb
    56ef2caf GITServerHandler.m (Scott 2009-01-05 153)

这个功能很有用  
通常来说，会认为复制代码过来的那个提交是最原始的提交  
因为那是第一次在这个文件中修改了这几行  
但 Git 会告诉第一次写这几行代码的那个提交才是原始提交，即使这是在另外一个文件里写的

--------------------

# 2. 二分查找 #

当知道问题是在哪里引入的情况下文件标注可以帮助你查找问题  
如果不知道哪里出了问题，并且自从上次可以正常运行到现在已经有数十个或者上百个提交  
这个时候可以使用 `git bisect` 来帮助查找  
它对你的提交历史进行二分查找，尽快找到是哪一个提交引入了问题

假设刚刚在线上环境部署了你的代码，接着收到一些 bug 反馈  
但这些 bug 在你之前的开发环境里没有出现过  
重新查看了你的代码，发现这个问题是可以被重现的  
但是不知道哪里出了问题

首先执行 `git bisect start` 来启动  
接着执行 `git bisect bad` 来告诉系统当前你所在的提交是有问题的  
然后必须使用 `git bisect good <good_commit>`，告诉 `bisect` 已知的最后一次正常状态是哪次提交：

$ git bisect start
    $ git bisect bad
    $ git bisect good v1.0
    Bisecting: 6 revisions left to test after this
    [ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo

Git 发现在你标记为正常的提交（v1.0）和当前的错误版本之间有大约12次提交  
于是 Git 检出中间的那个提交

现在可以执行测试，看看在这个提交下问题是不是还是存在  
如果还存在，说明问题是在这个提交之前引入的  
如果问题不存在，说明问题是在这个提交之后引入的

假设测试结果是没有问题的，你可以通过 `git bisect good` 来告诉 Git，然后继续寻找

$ git bisect good
    Bisecting: 3 revisions left to test after this
    [b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing

现在在另一个提交上了，这个提交是刚刚那个测试通过的提交和有问题的提交的中点  
再一次执行测试，发现这个提交下是有问题的，因此你可以通过 `git bisect bad` 告诉 Git：

$ git bisect bad
    Bisecting: 1 revisions left to test after this
    [f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table

这个提交是正常的，现在 Git 拥有的信息已经可以确定引入问题的位置在哪里  
它会告诉你第一个错误提交的 `SHA-1` 值并显示一些提交说明，以及哪些文件在那次提交里被修改过  
这样就可以找出引入 bug 的根源：

$ git bisect good
    b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit
    commit b047b02ea83310a70fd603dc8cd7a6cd13d15c04
    Author: PJ Hyett <pjhyett@example.com>
    Date:   Tue Jan 27 14:48:32 2009 -0800
    
        secure this thing
    
    :040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730
    f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M  config

当你完成这些操作之后  
应该执行 `git bisect reset` 重置你的 HEAD 指针到最开始的位置  
否则会停留在一个奇怪的状态：

$ git bisect reset

事实上，如果有一个脚本在项目是正常的情况下返回 0，在不正常的情况下返回非 0  
可以使 `git bisect` 自动化这些操作  
首先，设定好项目正常以及不正常所在提交的二分查找范围  
可以通过 `bisect start` 命令的参数来设定这两个提交  
第一个参数是项目不正常的提交，第二个参数是项目正常的提交：

$ git bisect start HEAD v1.0
    $ git bisect run test-error.sh

Git 会自动在每个被检出的提交里执行 `test-error.sh`，直到找到项目第一个不正常的提交  
也可以执行 `make` 或者 `make tests` 或者其他东西来进行自动化测试

--------------------

参考： [git][]  
以上内容，均根据git官网介绍删减、添加和修改组成

--------------------