它的原理很簡單，就是將程式碼提交的歷史，按照兩分法不斷縮小定位。所謂"兩分法"，就是將程式碼歷史一分為二，確定問題出在前半部分，還是後半部分，不斷執行這個過程，直到範圍縮小到某一次程式碼提交。
本文透過一個例項，解釋如何使用這個命令。下面是一個程式碼庫，請將它克隆到本地。
$ git clone [email protected]:bradleyboy/bisectercise.git $ cd bisectercise
這個庫是一個網頁index.html，在瀏覽器開啟這個網頁。
$ open index.html
網頁上是一個計數器，有兩個按鈕。點選+號按鈕，可以看到計數器沒有遞增，反而遞減，這說明程式碼有問題。
現在，就要來查詢，到底哪一次程式碼提交，引入了錯誤。首先，檢查一下程式碼提交歷史。
$ git log --pretty=oneline
可以看到，這個庫一共有101次提交。最早的第一次提交的雜湊是4d83cf。
git bisect start命令啟動查錯，它的格式如下。
$ git bisect start [終點] [起點]
上面程式碼中，"終點"是最近的提交，"起點"是更久以前的提交。它們之間的這段歷史，就是差錯的範圍。
這個例子中，我們選擇全部的程式碼歷史。起點是第一次提交4d83cf，終點是最近一次的HEAD。當然，指定其他範圍也可以。
$ git bisect start HEAD 4d83cf
執行上面的命令以後，程式碼庫就會切換到這段範圍正當中的那一次提交，本例是第51次提交。
現在重新整理瀏覽器，點選+按鈕，發現可以正常遞增。使用git bisect good命令，標識本次提交（第51次）沒有問題。
$ git bisect good
既然第51次提交沒有問題，就意味著錯誤是在程式碼歷史的後半段引入的。執行上面的命令，Git 就自動切換到後半段的中點（第76次提交）。
現在重新整理瀏覽器，點選+按鈕，發現不能正常遞增。使用git bisect bad命令，標識本次提交（第76）有問題。
$ git bisect bad
執行上面的命令以後，Git 就自動切換到第51次到第76次的中點（第63次提交）。
接下來，不斷重複這個過程，直到成功找到出問題的那一次提交為止。這時，Git 會給出如下的提示。
b47892 is the first bad commit
既然找到那個有問題的提交，就可以檢查程式碼，確定具體是什麼錯誤。
然後，使用git bisect reset命令，退出查錯，回到最近一次的程式碼提交。
$ git bisect reset
現在就可以開始修復錯誤了。
（完）