Git 調(diào)試

Git 同樣提供了一些工具來幫助你調(diào)試項(xiàng)目中遇到的問題。由于 Git 被設(shè)計(jì)為可應(yīng)用于幾乎任何類型的項(xiàng)目，這些工具是通用型，但是在遇到問題時(shí)可以經(jīng)常幫助你查找缺陷所在。

文件標(biāo)注

如果你在追蹤代碼中的缺陷想知道這是什么時(shí)候?yàn)槭裁幢灰M(jìn)來的，文件標(biāo)注會(huì)是你的最佳工具。它會(huì)顯示文件中對(duì)每一行進(jìn)行修改的最近一次提交。因此，如果你發(fā)現(xiàn)自己代碼中的一個(gè)方法存在缺陷，你可以用git blame來標(biāo)注文件，查看那個(gè)方法的每一行分別是由誰在哪一天修改的。下面這個(gè)例子使用了-L選項(xiàng)來限制輸出范圍在第12至22行：

$ git blame -L 12,22 simplegit.rb
^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 12)  def show(tree = 'master')
^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 13)   command("git show #{tree}")
^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 14)  end
^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 15)
9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 16)  def log(tree = 'master')
79eaf55d (Scott Chacon  2008-04-06 10:15:08 -0700 17)   command("git log #{tree}")
9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 18)  end
9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 19)
42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 20)  def blame(path)
42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21)   command("git blame #{path}")
42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22)  end

請(qǐng)注意第一個(gè)域里是最后一次修改該行的那次提交的 SHA-1 值。接下去的兩個(gè)域是從那次提交中抽取的值——作者姓名和日期——所以你可以方便地獲知誰在什么時(shí)候修改了這一行。在這后面是行號(hào)和文件的內(nèi)容。請(qǐng)注意^4832fe2提交的那些行，這些指的是文件最初提交的那些行。那個(gè)提交是文件第一次被加入這個(gè)項(xiàng)目時(shí)存在的，自那以后未被修改過。這會(huì)帶來小小的困惑，因?yàn)槟阋呀?jīng)至少看到了Git使用^來修飾一個(gè)提交的SHA值的三種不同的意義，但這里確實(shí)就是這個(gè)意思。

另一件很酷的事情是在 Git 中你不需要顯式地記錄文件的重命名。它會(huì)記錄快照然后根據(jù)現(xiàn)實(shí)嘗試找出隱式的重命名動(dòng)作。這其中有一個(gè)很有意思的特性就是你可以讓它找出所有的代碼移動(dòng)。如果你在git blame后加上-C，Git會(huì)分析你在標(biāo)注的文件然后嘗試找出其中代碼片段的原始出處，如果它是從其他地方拷貝過來的話。最近，我在將一個(gè)名叫GITServerHandler.m的文件分解到多個(gè)文件中，其中一個(gè)是GITPackUpload.m。通過對(duì)GITPackUpload.m執(zhí)行帶-C參數(shù)的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)

這真的非常有用。通常，你會(huì)把你拷貝代碼的那次提交作為原始提交，因?yàn)檫@是你在這個(gè)文件中第一次接觸到那幾行。Git可以告訴你編寫那些行的原始提交，即便是在另一個(gè)文件里。

二分查找

標(biāo)注文件在你知道問題是哪里引入的時(shí)候會(huì)有幫助。如果你不知道，并且自上次代碼可用的狀態(tài)已經(jīng)經(jīng)歷了上百次的提交，你可能就要求助于bisect命令了。bisect會(huì)在你的提交歷史中進(jìn)行二分查找來盡快地確定哪一次提交引入了錯(cuò)誤。

例如你剛剛推送了一個(gè)代碼發(fā)布版本到產(chǎn)品環(huán)境中，對(duì)代碼為什么會(huì)表現(xiàn)成那樣百思不得其解。你回到你的代碼中，還好你可以重現(xiàn)那個(gè)問題，但是找不到在哪里。你可以對(duì)代碼執(zhí)行bisect來尋找。首先你運(yùn)行g(shù)it bisect start啟動(dòng)，然后你用git bisect bad來告訴系統(tǒng)當(dāng)前的提交已經(jīng)有問題了。然后你必須告訴bisect已知的最后一次正常狀態(tài)是哪次提交，使用git bisect good [good_commit]：

$ 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 發(fā)現(xiàn)在你標(biāo)記為正常的提交(v1.0)和當(dāng)前的錯(cuò)誤版本之間有大約12次提交，于是它檢出中間的一個(gè)。在這里，你可以運(yùn)行測(cè)試來檢查問題是否存在于這次提交。如果是，那么它是在這個(gè)中間提交之前的某一次引入的；如果否，那么問題是在中間提交之后引入的。假設(shè)這里是沒有錯(cuò)誤的，那么你就通過git bisect good來告訴 Git 然后繼續(xù)你的旅程：

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

現(xiàn)在你在另外一個(gè)提交上了，在你剛剛測(cè)試通過的和一個(gè)錯(cuò)誤提交的中點(diǎn)處。你再次運(yùn)行測(cè)試然后發(fā)現(xiàn)這次提交是錯(cuò)誤的，因此你通過git bisect bad來告訴Git：

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

這次提交是好的，那么 Git 就獲得了確定問題引入位置所需的所有信息。它告訴你第一個(gè)錯(cuò)誤提交的 SHA-1 值并且顯示一些提交說明以及哪些文件在那次提交里修改過，這樣你可以找出缺陷被引入的根源：

$ 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

當(dāng)你完成之后，你應(yīng)該運(yùn)行g(shù)it bisect reset來重設(shè)你的HEAD到你開始前的地方，否則你會(huì)處于一個(gè)詭異的地方：

$ git bisect reset

這是個(gè)強(qiáng)大的工具，可以幫助你檢查上百的提交，在幾分鐘內(nèi)找出缺陷引入的位置。事實(shí)上，如果你有一個(gè)腳本會(huì)在工程正常時(shí)返回0，錯(cuò)誤時(shí)返回非0的話，你可以完全自動(dòng)地執(zhí)行g(shù)it bisect。首先你需要提供已知的錯(cuò)誤和正確提交來告訴它二分查找的范圍。你可以通過bisect start命令來列出它們，先列出已知的錯(cuò)誤提交再列出已知的正確提交：

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

這樣會(huì)自動(dòng)地在每一個(gè)檢出的提交里運(yùn)行test-error.sh直到Git找出第一個(gè)破損的提交。你也可以運(yùn)行像make或者make tests或者任何你所擁有的來為你執(zhí)行自動(dòng)化的測(cè)試。