この章の答え
同じ判定で good と bad を区別し、最初に変わった commit を探す。
数百の commit を順番に試す代わりに、良かった地点と悪い地点の間を半分ずつ絞ります。ただし探索の信頼性は、「この commit は良いか」を毎回同じ意味で判定できるかにかかっています。
01｜図でつかむ
判定できない commit は skip。ビルドできないことと、調査中のバグがあることを混同しない。
02｜3つのポイントで理解する
1. まず両端で同じ症状を確認する
good と bad では、同じ再現手順と期待値を使います。テストが途中の版で使えなくなる場合は、判定方法の互換性も考える必要があります。
2. 判定スクリプトの終了コードを決める
git bisect run では 0 が good、1〜127 のうち125以外が bad、125 が skip です。ツール不足などでテスト不能な状態を、症状の再現として bad にしないよう区別します。
3. 候補を独立に確かめる
探索結果が出たら、候補とその前の commit を同じ条件で比較します。skip が多いと候補を一つに絞れないこともあります。終わったら git bisect reset で探索状態を終了します。
03｜ソースで確かめる
以下は専用の作業コピーで使う手順のひな型です。山括弧の commit とスクリプトのパスは、確認済みの値に置き換えます。
git bisect start
# 確認済みの commit を指定する
git bisect bad <bad-commit>
git bisect good <good-commit>
git bisect run python3 /absolute/path/to/oracle.py
git bisect reset小さく試す
専用の作業コピーで行う前提で、good・bad・判定不能の条件を文章にします。原稿の /tmp のスクリプトは付属していないため、自分の判定を用意します。
04｜30秒で復習
- 両端を同じ条件で判定する。
- 0・bad・125 の意味を区別する。
- 結果の commit と直前の挙動を再確認する。