例として、プロジェクトのバージョンv2.6.13-rc2で機能していたはずの機能が壊れたコミットを見つけようとしているとします。以下のように二分探索セッションを開始します。

少なくとも1つの悪いコミットと1つの良いコミットを指定すると、git bisectはその履歴範囲の中間のコミットを選択し、それをチェックアウトして、次のような出力を表示します。

これで、チェックアウトされたバージョンをコンパイルしてテストする必要があります。そのバージョンが正しく動作する場合は、次のように入力します。

そのバージョンが壊れている場合は、次のように入力します。

するとgit bisectは次のように応答します。

このプロセスを繰り返します。ツリーをコンパイルし、テストし、それが良いか悪いかに応じてgit bisect goodまたはgit bisect badを実行して、次にテストする必要があるコミットを尋ねます。

最終的に検査するリビジョンがなくなると、コマンドは最初の悪いコミットの説明を出力します。refs/bisect/badという参照は、そのコミットを指したままになります。

二分探索セッションの後、二分探索の状態をクリーンアップし、元のHEADに戻すには、以下のコマンドを発行します。

デフォルトでは、これによりツリーはgit bisect startの前にチェックアウトされていたコミットに戻ります。(新しいgit bisect startも、古い二分探索の状態をクリーンアップするため、同様の動作をします。)

オプションの引数を指定すると、代わりに別のコミットに戻ることができます。

例えば、git bisect reset bisect/badは最初の悪いリビジョンをチェックアウトしますが、git bisect reset HEADは現在の二分探索コミットに留まり、コミットの切り替えを一切行いません。

バグを導入したコミットを探しているのではなく、何らかの「古い」状態と「新しい」状態の間で変更を引き起こしたコミットを探している場合があります。例えば、特定の修正を導入したコミットを探しているかもしれません。あるいは、ソースコードのファイル名がすべて会社の命名標準に変換された最初のコミットを探しているかもしれません。その他、何でも構いません。

そのような場合、「変更前の状態」と「変更後の状態」を指すのに「良い」と「悪い」という用語を使うと非常に混乱することがあります。そこで、代わりに「良い」と「悪い」の代わりにそれぞれ「古い」と「新しい」という用語を使うことができます。(ただし、1つのセッション内で「良い」と「悪い」を「古い」と「新しい」と混ぜることはできません。)

このより一般的な使い方では、何らかのプロパティを持つ「新しい」コミットと、そのプロパティを持たない「古い」コミットをgit bisectに提供します。git bisectがコミットをチェックアウトするたびに、そのコミットがそのプロパティを持っているかどうかをテストします。持っている場合は、そのコミットを「新しい」とマークします。持っていない場合は、「古い」とマークします。二分探索が完了すると、git bisectはどのコミットがそのプロパティを導入したかを報告します。

「良い」と「悪い」の代わりに「古い」と「新しい」を使用するには、引数なしでgit bisect startを実行し、次に以下のコマンドを実行してコミットを追加する必要があります。

探し求める変更の前だったコミットを示すため、あるいは

変更の後だったコミットを示すため。

現在使用されている用語のリマインダーを得るには、

git bisect terms --term-oldまたはgit bisect terms --term-goodで古い用語のみを取得できます。git bisect terms --term-newとgit bisect terms --term-badは、探し求める変更よりも新しいコミットをどのように呼ぶかを学習するために使用できます。

「bad」/「good」や「new」/「old」の代わりに独自の用語を使用したい場合は、reset、startなどの既存のbisectサブコマンド以外の好きな名前を選択して、以下のように二分探索を開始できます。

例えば、パフォーマンス低下を導入したコミットを探している場合、次のように使用できます。

あるいは、バグを修正したコミットを探している場合、次のように使用できます。

次に、コミットをマークするには、git bisect goodとgit bisect badの代わりにgit bisect <term-old>とgit bisect <term-new>を使用します。

二分探索プロセス中にgitkで現在残っている容疑者を見るには、以下のコマンドを発行します(サブコマンドviewはvisualizeの代替として使用できます)。

Gitは、X Window System環境のUnixシステムで設定されるDISPLAY、インタラクティブデスクトップセッションでCygwinで設定されるSESSIONNAME、Msys2およびGit for Windowsで設定されるMSYSTEM、macOSのインタラクティブデスクトップセッションで設定される可能性のあるSECURITYSESSIONIDなど、様々な環境変数を通じてグラフィカル環境を検出します。

これらの環境変数のいずれも設定されていない場合、代わりにgit logが使用されます。また、-pや--statなどのコマンドラインオプションを指定することもできます。

リビジョンを「良い」または「悪い」とマークした後、これまでに何が行われたかを表示するには、以下のコマンドを発行します。

リビジョンの状態の指定に誤りがあったことが判明した場合、このコマンドの出力をファイルに保存し、不正確なエントリを削除して編集し、以下のコマンドを発行して修正された状態に戻すことができます。

二分探索セッションの途中で、提案されたリビジョンがテストに適していないとわかっている場合（例えば、ビルドに失敗し、その失敗が追跡しているバグとは関係ないことがわかっている場合）、代わりに近くのコミットを手動で選択してテストすることができます。

例

次に、選択したリビジョンをコンパイルしてテストし、その後、通常の方法でそのリビジョンを「良い」または「悪い」とマークします。

自分で近くのコミットを選択する代わりに、以下のコマンドを発行してGitにそれを実行させることもできます。

ただし、探しているコミットに隣接するコミットをスキップした場合、Gitはそれらのコミットのうちどれが最初の悪いコミットであったかを正確に特定することができません。

また、単一のコミットだけでなく、範囲表記を使用してコミットの範囲をスキップすることもできます。例えば、

これは、v2.5以降のコミットのうち、v2.6を含むコミットはテストすべきではないことを二分探索プロセスに伝えます。

範囲の最初のコミットもスキップしたい場合は、次のコマンドを発行することに注意してください。

これは、v2.5とv2.6の間のコミット (両端を含む) はスキップすべきであることを二分探索プロセスに伝えます。

追跡している問題にどのツリーの一部が関係しているかが分かっている場合、bisect startコマンドを発行する際にパススペックパラメータを指定することで、試行回数をさらに減らすことができます。

複数の良いコミットを事前に知っている場合、bisect startコマンドを発行する際に悪いコミットの直後にすべての良いコミットを指定することで、二分探索空間を絞り込むことができます。

現在のソースコードが良いか悪いかを判断できるスクリプトがある場合、以下のコマンドを発行して二分探索を実行できます。

上記の例のスクリプト(my_script)は、現在のソースコードが良い/古い場合は終了コード0で終了し、現在のソースコードが悪い/新しい場合は125を除く1から127(両端を含む)のコードで終了する必要があることに注意してください。

その他の終了コードは、二分探索プロセスを中止します。exit(-1)で終了するプログラムは、$?=255になります（exit(3)マニュアルページ参照）。値は& 0377で切り捨てられるためです。

特別な終了コード125は、現在のソースコードをテストできない場合に使用されます。スクリプトがこのコードで終了した場合、現在のリビジョンはスキップされます（上記のgit bisect skipを参照）。125は、この目的のために使用する最高の実用的な値として選ばれました。なぜなら、126と127はPOSIXシェルによって特定のエラー状態を通知するために使用されるためです（127はコマンドが見つからない場合、126はコマンドは見つかったが実行できない場合です。これらは、bisect runの観点からは、スクリプトにおける通常のエラーであるため、これらの詳細は重要ではありません）。

二分探索セッション中に、一時的な変更（例：ヘッダーファイルでs/#define DEBUG 0/#define DEBUG 1/、または「このコミットを持たないリビジョンには、この二分探索が関心のない別の問題を回避するためにこのパッチを適用する必要がある」）をテスト中のリビジョンに適用したいと часто思うことがあります。

このような状況に対処するため、内部のgit bisectが次にテストするリビジョンを見つけた後、スクリプトはコンパイル前にパッチを適用し、実際のテストを実行し、その後、リビジョン（必要に応じてパッチを適用したもの）がテストに合格したかどうかを判断し、ツリーを元の状態に戻すことができます。最後に、スクリプトは実際のテストのステータスで終了し、git bisect runコマンドループが二分探索セッションの最終結果を決定できるようにする必要があります。

短い使い方説明を得るにはgit bisectを、長い使い方説明を得るにはgit bisect helpまたはgit bisect -hを使用します。