git bisect ステップ数計算機｜バグ特定までの回数と時間を見積もる

git bisect でバグの原因コミットを突き止めるまでに、何回 good／bad を答える必要があるのか。対象コミット数を入れるだけで、必要ステップ数 ⌈log₂(N)⌉ と、1 ステップの所要時間から見積もった総時間が分かります。二分探索が範囲を半分ずつ畳んでいく様子も段階バーで確認できます。

💡 このツールについて

git bisect は、正常だった地点（good）とバグが出た地点（bad）の間を二分探索し、原因コミットを O(log N) で絞り込むデバッグコマンドです。1000 件のコミットがあっても、1 件ずつ確認すれば最悪 1000 回ですが、二分探索なら 10 回前後で済みます。

ただ、実際に bisect を始める前に「これは何回くらい付き合うことになるのか」「CI が遅いから 1 回 5 分かかる、トータルどのくらい?」が読めないと、着手をためらいがちです。このツールは対象コミット数からステップ数を ⌈log₂(N)⌉ で算出し、1 ステップの所要時間を掛けて総時間の目安を出します。さらに good／bad の位置が分かっていれば、その間だけを探索範囲として絞り込めます。範囲を狭めるほどステップ数も減るので、「どこまで範囲を絞れば何回減るのか」を入力しながら把握できます。

🧐 よくある質問

Q. ステップ数はどう計算していますか? 探索範囲のコミット数を N として ⌈log₂(N)⌉ で求めます。二分探索は 1 回ごとに範囲が半分になるため、N を 1 まで絞り込むのに必要な分割回数がこの値です。N=1（範囲に 1 件しかない）なら 0 ステップになります。

Q. good／bad の位置は必須ですか? 任意です。空欄なら good を履歴の先頭（0）、bad を最新（HEAD）とみなし、全コミットを範囲として計算します。位置が分かっている場合に入力すると、その区間だけが探索対象になり、ステップ数と時間が減ります。

Q. 所要時間の見積もりはどこまで正確ですか? ステップ数 × 1 ステップの所要時間という単純な掛け算です。ビルドや手動テストにかかる平均時間を入れた概算で、CI のキュー待ちや bisect の中断・再開は含みません。着手前の規模感をつかむ目安として使ってください。

Q. git bisect run で自動化したときの回数も同じですか? 同じです。git bisect run <スクリプト> はテストの good／bad 判定を自動化するだけで、二分探索の回数自体は変わりません。手動で答えるか、スクリプトに答えさせるかの違いだけなので、ステップ数の見積もりはそのまま使えます。

📚 二分探索が速い理由

bisect の語源は「二等分する」です。範囲を半分にするたびに残りの候補が半分になるので、N 件を 1 件まで絞るには「N を何回 2 で割れば 1 になるか」＝ log₂(N) 回で済みます。コミット数が倍になっても増えるステップはたった 1 回。1000 件で約 10 回、100 万件でも約 20 回です。この「件数が増えても回数がほとんど増えない」性質こそ、大規模リポジトリでも bisect が実用的であり続ける理由です。なお、ビルドが壊れて判定できないコミットは git bisect skip で飛ばせますが、skip が増えると有効な分割が減り、実際の回数は理論値より少し増えることがあります。