こんにちは。現場で泥臭いデバッグに追われているエンジニアの皆さん、お疲れ様です。
「昨日までは動いていたのに、なぜか今日動かない」。そんな悪夢のような瞬間、皆さんも一度は経験したことがあるでしょう。犯人（コミット）を探すために、ログを眺めながら一つずつチェックアウトを繰り返していませんか？
もしそうなら、今日でその苦行とはお別れです。今回は、Gitが標準で備えている最強の武器「git bisect」を使って、バグの混入箇所を二分探索で瞬時に突き止める「外科手術のようなデバッグ術」を伝授します。
—
1. なぜ「git bisect」が最強なのか？
`git bisect`は、二分探索（Binary Search）アルゴリズムをGitのコミット履歴に適用する機能です。
- 人力の限界: 100個のコミットを一つずつチェックしていたら、最悪100回の手順が必要です。
- bisectの威力: 二分探索なら、たったの7回（log2(100)≒6.64）のチェックで犯人を特定できます。
「いつ壊れたか分からない」という不安を「数学的な確信」に変える。これこそが、プロのDevOpsエンジニアが真っ先に手を付けるデバッグ術なのです。
—
2. まずはここから：bisectの基本セットアップ
GitはCLIに標準で組み込まれているため、インストールは不要です。準備ができたら、リポジトリのルートで以下の呪文を唱えてください。
bisectモードを開始
git bisect start
現在のコミットが「壊れている」ことを伝える
git bisect bad
最後に正常だったコミット（ハッシュ値）を指定して「正常」を伝える
git bisect good <古いコミットのハッシュ>
これだけで、Gitは自動的に「正常」と「異常」の中間のコミットへチェックアウトしてくれます。あとはあなたがテストを実行し、`git bisect good` か `git bisect bad` を繰り返すだけ。これだけでも十分速いですが、さらにその先へ行きましょう。
—
3. 自動化のハック：スクリプト連携で「犯人を放置で特定する」
人間が手動でテストするのはもう古い。テストコードがあるなら、スクリプトに自動判定させるのがDevOpsの流儀です。
以下の手順で、コーヒーを飲んでいる間にバグを特定しましょう。
ステップ1：テスト用スクリプトの作成
プロジェクト直下に、成功なら終了コード `0`、失敗なら `1` 以外を返すスクリプト（`test.sh`）を用意します。
!/bin/bash
test.sh
ここでビルドとテストを実行する
npm run build && npm test
終了コードをそのままbisectに渡すのがミソ
exit $?
※ `chmod +x test.sh` を忘れずに。
ステップ2：自動二分探索の実行
Gitに「このスクリプトが成功したか失敗したかで判断してくれ」と命令します。
全自動デバッグ開始！
git bisect run ./test.sh
何が起きているか分かりますか？
Gitが自動的にチェックアウトし、スクリプトを実行し、結果に基づいて次のポイントへジャンプする。これをバグの混入箇所が見つかるまで全自動で繰り返します。あなたはPCの前で待っているだけで、最後に「〇〇というコミットが犯人です！」と突きつけられるのです。
—
4. 現場で震えるほど役立つ「極限の知見」
最後に、現場で生き残るための「プロのコツ」を二つだけ授けます。
- `git bisect skip` を使いこなせ:
もし、中間地点のコミットが「たまたまビルドエラーでテストが実行できない」状態だったらどうしますか？ そこで諦めてはいけません。`git bisect skip` を使えば、そのコミットを避けて別の候補を探してくれます。
- 依存関係の罠に注意:
大規模プロジェクトでは、`npm install` や `bundle install` が各コミットで必要な場合があります。`test.sh` の先頭に、依存関係を再構築する処理を必ず含めてください。ここを怠ると、偽のバグに踊らされることになります。
—
最後に
デバッグとは「犯人探し」ではなく「歴史の再検証」です。Git bisectをマスターすれば、あなたはもう「いつ壊れたんだろう？」と悩む必要はありません。
「ツールにできることはツールに任せ、人間はロジックの解決に集中する」。これこそが、プロダクトを最速で前に進める唯一の道です。
さあ、次のバグが出たら、迷わず `git bisect start` を叩いてください。それが、あなたの開発ライフを劇的に楽にする第一歩です！