假設你在項目的'2.6.18'版上面工作, 但是你當前的代碼(master)崩潰(crash)了. 有時解決這種問題的最好辦法是: 手工逐步恢復(brute-force regression)項目歷史,　找出是哪個提交(commit)導致了這個問題. 但是 linkgit:git-bisect[1](http://gitbook.liuhui998.com/%E4%BA%8C%E5%88%86%E6%9F%A5%E6%89%BE)?可以更好幫你解決這個問題: ~~~ $ 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](http://www.kernel.org/pub/software/scm/git/docs/git-show.html)?命令查看這個提交(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"的狀態。