章: 第6章: 現場で差がつく補助操作
不具合調査でつらいのは「原因が多すぎる」こと
実務でよくあるのが、「いつから壊れたのかわからない」という状況です。
- 1週間前は動いていた
- その間に何十コミットも入っている
- どの変更が原因か見当がつかない
このとき、最新から順番に全部読むのはかなり大変です。
そこで使えるのが bisect です。
bisect は、正常な地点と異常な地点の間を二分探索して、原因コミットを絞り込むための機能です。
どういう考え方か
やることはシンプルです。
- 今は壊れているとわかっている地点を
bad - 以前は正常だったとわかっている地点を
good
として、その間のコミットを半分ずつ試していきます。
git bisect start
git bisect bad
git bisect good <正常だったコミットID>
すると Git が候補を1つずつ示してくれるので、その時点で動くか壊れるかを判定して進めます。
なぜ強いのか
10件、20件ならまだしも、100件近い変更の中から原因を探すのは人力だとかなり厳しいです。
bisect を使うと、総当たりではなく半分ずつ候補を削れるので、かなり効率よく絞れます。
つまり bisect の価値は、Gitコマンドを増やすことではなく、調査コストを一気に下げること にあります。
実務で使う場面
- 不具合がいつ混入したか特定したいとき
- 再現条件が明確で、正常/異常を判定できるとき
- 変更量が多く、人力で履歴を追うのが重いとき
特に「テストを回せば壊れているか分かる」状態だと、bisect はかなり強力です。
使う前に必要なこと
bisect は万能ではありません。少なくとも次が必要です。
- 何をもって正常/異常とするか決まっている
- あるコミットをチェックしたときに判定できる
ここが曖昧だと、探索の精度が落ちます。
つまり bisect は「Gitの魔法」ではなく、再現できる不具合調査を効率化する手段です。
実務での位置づけ
| 調査方法 | 特徴 |
git log や差分を目視で追う |
小規模変更なら有効 |
bisect で絞る |
候補が多いときに強い |
原因の見当があるなら log や show で十分なこともあります。ただ、候補が広すぎるときの bisect はかなり頼りになります。
チェックポイント:
bisectは「壊れた理由を自動で教える」機能ではなく、「怪しいコミットを効率よく絞り込む」機能です。
まとめ & 次のステップ
bisectは正常地点と異常地点の間を二分探索で絞る機能- 不具合混入コミットの特定に強い
- 正常/異常を判定できることが前提になる
- 候補が多いときほど効果が大きい
- Gitは履歴管理だけでなく調査の道具としても強力
次回はコンフリクト解消の実践を扱います。 コンフリクトは避けるだけでなく、起きたときにどう落ち着いて処理するかが実務では重要です。
