例如你剛剛推送了一個代碼發佈版本到產品環境中,得到一些在你開發環境中沒有發生的錯誤報告,而你對代碼為什麼會表現成那樣百思不得其解。你回到你的代碼中,還好你可以重現那個錯誤,但是找不到問題在哪裡。你可以對代碼執行 bisect 來尋找。首先你執行 git bisect start 啟動,然後你用 git bisect bad 來告訴系統當前的提交已經有問題了。然後你必須告訴 bisect 已知的最後一次正常狀態是哪次提交,使用 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 發現在你標記為正常的提交(v1.0)和當前的錯誤版本之間有大約12次提交,於是它 check out 中間的一個。在這裡,你可以進行測試,檢查問題是否存在於這次提交。如果是,那麼它是在這個中間提交之前的某一次引入的;如果否,那麼問題是在中間提交之後引入的。假設這裡是沒有錯誤的,那麼你就通過 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 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 到你開始前的地方,否則你會處於一個詭異的狀態: