git はファイルの集合の履歴を格納するツールとして とても良く考慮されたツールです。 ファイル階層の中身を圧縮したスナップショットと スナップショット間の関係を表す "commit" を格納することで これを実現しています。
git は非常に柔軟で高速に動作するプロジェクトの履歴探索ツールです。
プロジェクトにバグを入れ込んだコミットを見つける為の便利な 特殊ツールの説明からはじめましょう。
プロジェクトのバージョン 2.6.18 では動作するが、"master" ブランチの 最新バージョンではクラッシュするとしましょう。 そのようなリグレッションの原因を探し出す最良の方法は プロジェクトの履歴を総当たりで検索し、問題を引き起こす特定のコミットを見つけることです。 git-bisect(1) コマンドはこの作業の手伝いをしてくれます：
$ 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" を実行すると、git は一時的に "bisect" という 名前の新しいブランチに移動していることがわかります。 このブランチは、"master" からは到達可能だが、v2.6.18 からは到達できない コミット(id が 65934… のコミット)を指しています。 コンパイルとテストをし、クラッシュするかを確認します。 もしクラッシュするのなら、以下のように：
$ git bisect bad
Bisecting: 1769 revisions left to test after this
[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings
として、より古いバージョンを確認します。このように git に各段階でそのバージョンが good か bad かを伝える作業を続け、 テストすべきリビジョンの残数は各回で約半分ずつに削られていきます。
(今回の場合では)約13回テストした後、罪を犯したコミットの id を 見つけることができます。そのコミットに対して git-show(1) を実行し、 誰がそのコミットを書いたかを見つけ出し、コミットの id を添えて、 バグレポートをメールします。最後に、
$ git bisect reset
を実行し、以前いたブランチに戻り、一時作成した "bisect" ブランチを 削除します。
注意：git-bisect が各状態でチェックアウトするバージョンは単なる提案にすぎません。 必要であるなら違うバージョンをテストすることもできます。 例えば、関係のない変更をしているコミット上にいるかもしれません； その時は、 TODO: 訳を見直し
$ git bisect visualize
を実行します。gitk が実行され、選択されているコミットに "bisect" というマーカーが付けられます。 TODO: 訳を見直し
$ git reset --hard fb47ddb2db...
テストし、"bisect good" または "bisect bad" の適切な方を実行し、 作業を続けます。