查找問題的利器 - Git Bisect

【轉自】查找問題的利器 - Git Bisect

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

假設你在項目的'2.6.18'版上面工做, 可是你當前的代碼(master)崩潰(crash)了. 有時解決這種問題的最好辦法是: 手工逐步恢復(brute-force regression)項目歷史,　找出是哪一個提交(commit)致使了這個問題. 可是 linkgit:git-bisect1 能夠更好幫你解決這個問題:

$ git bisect start
$ git bisect good v2.6.18
$ git bisect bad master
Bisecting: 3537 revisions left to test after this
[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]

若是你如今運行"git branch",　會發現你如今所在的是"no branch"(譯者注:這是進行git bisect的一種狀態). 這時分支指向提交（commit):"69543", 此提交恰好是在"v2.6.18"和「master"中間的位置. 如今在這個分支裏,　編譯並測試項目代碼, 查看它是否崩潰(crash). 假設它此次崩潰了, 那麼運行下面的命令:

$ git bisect bad
Bisecting: 1769 revisions left to test after this
[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings

如今git自動簽出(checkout)一個更老的版本. 繼續這樣作, 用"git bisect good","git bisect bad"告訴git每次簽出的版本是否沒有問題; 你如今能夠注意一下當前的簽出的版本, 你會發現git在用"二分查找(binary search)方法"簽出"bad"和"good"之間的一個版本(commit or revison).

在這個項目(case)中, 通過13次嘗試, 找出了致使問題的提交(guilty commit). 你能夠用 git show 命令查看這個提交(commit), 找出是誰作的修改，而後寫郵件給TA. 最後, 運行:

$ git bisect reset

這會到你以前(執行git bisect start以前)的狀態.

注意: git-bisect 每次所選擇簽出的版本, 只是一個建議; 若是你有更好的想法, 也能夠去試試手工選擇一個不一樣的版本.

運行: $ git bisect visualize

這會運行gitk, 界面上會標識出"git bisect"命令自動選擇的提交(commit). 你能夠選擇一個相鄰的提交(commit), 記住它的SHA串值, 用下面的命令把它簽出來:

$ git reset --hard fb47ddb2db...

而後進行測試, 再根據測試結果執行」bisect good"或是"bisect bad"; 就這樣反覆執行, 直到找出問題爲止.

譯者注: 關於"git bisect start"後的分支狀態, 譯文和原文不一致. 原文是說執行"git bisect start"後會建立一個名爲"bisect"的分支, 可是實際狀況倒是處於"no branch"的狀態.