git bisectの使い方｜実行ログで学ぶバグ混入コミットの特定

git bisectとは、「正常だったコミット」と「不具合があるコミット」を1つずつ教えると、その間を二分探索して、不具合が最初に入ったコミットを特定してくれる Git のコマンドです。 30コミットの間に原因があっても、確認は5回ほどで済みます。テストスクリプトを渡せば git bisect run で全自動にもできます。

この記事では、30コミットのサンプルリポジトリを作るスクリプトを用意し、手動の bisect、git bisect run による自動化、skip、--term-old / --term-new（「遅くなった」を探す）、log / replay / visualize、--first-parent をすべて実行し、そのログを省略せずに載せています。 終了コードの早見表、探索回数の目安、使える場面・使いにくい場面の判断表、つまずいたときの戻り方もまとめました。検証は Git 2.43.0 と Python 3.11 で行っています（2026年10月時点の Git 最新版は 2.56.0）。

git bisectの早見表

git bisect run の終了コード早見表

サンプルリポジトリを作る（30コミット）

次のスクリプトで、17番目に計算の不具合、23〜24番目にビルドできないコミット、26番目に処理が遅くなるコミットを含む30コミットを作ります。 日時を固定しているので、手元でもハッシュが同じになります（グローバル設定の影響を避けるため GIT_CONFIG_GLOBAL=/dev/null で実行しました）。

#!/usr/bin/env bash
# make_repo.sh：30コミットのサンプルリポジトリを作る
# （17番目で不具合、23〜24番目はビルド不可、26番目で遅くなる）
set -eu
rm -rf shop && git init -q -b main shop && cd shop
git config user.name "Dev"; git config user.email "dev@example.com"
export GIT_AUTHOR_DATE="2026-10-01T09:00:00+09:00" GIT_COMMITTER_DATE="2026-10-01T09:00:00+09:00"
cat > stock.py <<'PY'
import time

def total(items):
    """在庫の合計金額（数量×単価の合計）"""
    return sum(q * p for q, p in items)
PY
cat > test_stock.py <<'PY'
from stock import total
assert total([(2, 100), (1, 50), (3, 10)]) == 280, total([(2, 100), (1, 50), (3, 10)])
print("ok")
PY
git add . && git commit -q -m "c01: 在庫合計を実装"
git tag v1.0
for i in $(seq 2 30); do
  n=$(printf '%02d' "$i")
  echo "- 変更 $n" >> CHANGELOG.md
  case $i in
    17) sed -i 's/for q, p in items)/for q, p in items[:-1])/' stock.py; msg="c$n: 合計処理を整理";;
    23) echo "def label(x) return x" > util.py; msg="c$n: ラベル関数を追加（書きかけ）";;
    24) echo "def label(x) return str(x)" > util.py; msg="c$n: ラベル関数を修正（まだ構文エラー）";;
    25) echo "def label(x): return str(x)" > util.py; msg="c$n: ラベル関数の構文を修正";;
    26) sed -i 's/    return sum/    time.sleep(0.3)\n    return sum/' stock.py; msg="c$n: 監査ログ用の待機を追加";;
    *) msg="c$n: 小さな変更";;
  esac
  git add . && git commit -q -m "$msg"
done
git log --oneline | wc -l

GIT_CONFIG_GLOBAL=/dev/null ./make_repo.sh
cd shop && python3 test_stock.py

30
Traceback (most recent call last):
  File ".../shop/test_stock.py", line 2, in <module>
    assert total([(2, 100), (1, 50), (3, 10)]) == 280, total([(2, 100), (1, 50), (3, 10)])
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 250

最新のコミットでは合計が 280 ではなく 250 になっています。 タグ v1.0（最初のコミット）に戻すと ok が出るので、「v1.0 は正常、最新は不具合あり」という前提がそろいました。

手動で探す（start・bad・good・reset）

手順は「start → 今（最新）を bad → 正常だった v1.0 を good → Git が選んだコミットでテストして good / bad を答える」の繰り返しです。

git bisect start
git bisect bad
git bisect good v1.0

status: waiting for both good and bad commits
status: waiting for good commit(s), bad commit known
Bisecting: 14 revisions left to test after this (roughly 4 steps)
[567b9729d30e51bfe8a63881d3961fccc55bb607] c15: 小さな変更

Git が真ん中の c15 をチェックアウトしました。 ここでテストを実行して結果を答えます。以下、テストの結果と答えたコマンドを順に並べます。

--- 現在: c15: 小さな変更 / テスト: ok
$ git bisect good
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[208945a302dc529ab54dd47839bf973a8f2e3f06] c22: 小さな変更
--- 現在: c22: 小さな変更 / テスト: AssertionError: 250
$ git bisect bad
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[11f8e1f6d4d13b9278882357dca133659949c2a8] c18: 小さな変更
--- 現在: c18: 小さな変更 / テスト: AssertionError: 250
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 1 step)
[c965a361dfbf4654ee81e0ea889dfd53f949cb87] c17: 合計処理を整理
--- 現在: c17: 合計処理を整理 / テスト: AssertionError: 250
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[f79657f696afcfe72b1bc3998a717af8996747be] c16: 小さな変更
--- 現在: c16: 小さな変更 / テスト: ok
$ git bisect good
c965a361dfbf4654ee81e0ea889dfd53f949cb87 is the first bad commit
commit c965a361dfbf4654ee81e0ea889dfd53f949cb87
Author: Dev <dev@example.com>
Date:   Thu Oct 1 09:00:00 2026 +0900

    c17: 合計処理を整理

 CHANGELOG.md | 1 +
 stock.py     | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

5回のテストで、c17「合計処理を整理」が原因だと特定できました。 git show c965a36 を見ると、items が items[:-1] に変わり、最後の1件が合計から外れていたことがわかります。

終わったら reset で元に戻る

git bisect reset

Previous HEAD position was f79657f c16: 小さな変更
Switched to branch 'main'

bisect 中は HEAD が切り離された状態（detached HEAD）なので、終わったら必ず git bisect reset で開始前のブランチに戻ります。 git bisect reset <コミット> とすると、指定したコミットに移って終われます。

手順の流れ

flowchart TD
  A[git bisect start] --> B[git bisect bad（不具合ありのコミット）]
  B --> C[git bisect good（正常だったコミット）]
  C --> D[Git が真ん中をチェックアウト]
  D --> E{テスト結果}
  E -- 正常 --> F[git bisect good]
  E -- 不具合 --> G[git bisect bad]
  E -- 判定できない --> H[git bisect skip]
  F --> I{候補が1つ?}
  G --> I
  H --> I
  I -- いいえ --> D
  I -- はい --> J[first bad commit を表示]
  J --> K[git bisect reset]

git bisect runで自動化する

毎回テストして答える部分は、スクリプトに任せられます。 判定用のスクリプトはリポジトリの外に置くのがコツです。bisect は過去のコミットをチェックアウトするので、リポジトリ内に置くと古いコミットには存在しないことがあります。

#!/usr/bin/env bash
# ../check.sh：ビルドできなければ 125（skip）、テスト失敗なら 1（bad）、成功なら 0（good）
python3 -m py_compile ./*.py 2>/dev/null || exit 125
python3 test_stock.py >/dev/null 2>&1 || exit 1
exit 0

chmod +x ../check.sh
git bisect start HEAD v1.0
git bisect run ../check.sh

Bisecting: 14 revisions left to test after this (roughly 4 steps)
[567b9729d30e51bfe8a63881d3961fccc55bb607] c15: 小さな変更
running '../check.sh'
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[208945a302dc529ab54dd47839bf973a8f2e3f06] c22: 小さな変更
running '../check.sh'
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[11f8e1f6d4d13b9278882357dca133659949c2a8] c18: 小さな変更
running '../check.sh'
Bisecting: 0 revisions left to test after this (roughly 1 step)
[c965a361dfbf4654ee81e0ea889dfd53f949cb87] c17: 合計処理を整理
running '../check.sh'
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[f79657f696afcfe72b1bc3998a717af8996747be] c16: 小さな変更
running '../check.sh'
c965a361dfbf4654ee81e0ea889dfd53f949cb87 is the first bad commit
commit c965a361dfbf4654ee81e0ea889dfd53f949cb87
Author: Dev <dev@example.com>
Date:   Thu Oct 1 09:00:00 2026 +0900

    c17: 合計処理を整理

 CHANGELOG.md | 1 +
 stock.py     | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
bisect found first bad commit

手動と同じ順番でたどり、同じ c17 にたどり着きました。 git bisect start HEAD v1.0 のように、start に bad と good をまとめて渡すと手順が1行で済みます。

テストコマンドを直接渡す

スクリプトを用意しなくても、コマンドをそのまま渡せます。

git bisect run python3 test_stock.py
git bisect run npm test
git bisect run sh -c 'make && ./run-tests.sh'

pytest や npm test のように「失敗で 1 を返す」コマンドは、そのまま bad 判定に使えます。 ビルド失敗を skip にしたいときだけ、上の check.sh のように 125 を返すスクリプトにします。

終了コードの動きを確かめる

128 以上を返すと、探索は中断されます。

git bisect start HEAD v1.0
git bisect run sh -c 'exit 200'

running 'sh' '-c' 'exit 200'
error: bisect run failed: exit code 200 from 'sh' '-c' 'exit 200' is < 0 or >= 128

コマンドが見つからない（終了コード 127）ときは、Git が good のコミットでも試し、同じ結果なら止めてくれます。

git bisect run ./no_such.sh

running './no_such.sh'
'./no_such.sh': 1: ./no_such.sh: not found
[12744d60dbc08b7ec8e589edf2a89be82e326462] c01: 在庫合計を実装
running './no_such.sh'
'./no_such.sh': 1: ./no_such.sh: not found
error: bogus exit code 127 for good revision

bogus exit code 127 for good revision が出たら、スクリプトのパスや実行権限を確認します。リポジトリ内のスクリプトを ./ で渡して、古いコミットに存在しなかったときにもこの表示になります。

ビルドできないコミットをskipする

判定できないコミットは git bisect skip で飛ばすと、Git が近くの別のコミットを選び直します。 git bisect run では、スクリプトが 125 を返すと自動で skip になります。ここでは、26番目の「遅くなった」コミットを探しながら、構文エラーの c24 を自動で skip する様子を示します（遅さの判定は次の章で詳しく扱います）。

git bisect start --term-old=fast --term-new=slow HEAD HEAD~8
git bisect run ../check_speed.sh
git bisect log

Bisecting: 3 revisions left to test after this (roughly 2 steps)
[25862fb984452aeb80baef8dd58f291da3b675f4] c26: 監査ログ用の待機を追加
running '../check_speed.sh'
0.300s
Bisecting: 1 revision left to test after this (roughly 1 step)
[503b47ed2f17b0333e3be4deaccfd6a3d954c026] c24: ラベル関数を修正（まだ構文エラー）
running '../check_speed.sh'
Bisecting: 1 revision left to test after this (roughly 1 step)
[58cb38de908c6f318786a70e77b9bcd2e01d121a] c25: ラベル関数の構文を修正
running '../check_speed.sh'
0.000s
25862fb984452aeb80baef8dd58f291da3b675f4 is the first slow commit
bisect found first bad commit

# slow: [c8c28a8451fe6f66baa330c7cc22194b5381809d] c30: 小さな変更
# fast: [208945a302dc529ab54dd47839bf973a8f2e3f06] c22: 小さな変更
git bisect start '--term-old=fast' '--term-new=slow' 'HEAD' 'HEAD~8'
# slow: [25862fb984452aeb80baef8dd58f291da3b675f4] c26: 監査ログ用の待機を追加
git bisect slow 25862fb984452aeb80baef8dd58f291da3b675f4
# skip: [503b47ed2f17b0333e3be4deaccfd6a3d954c026] c24: ラベル関数を修正（まだ構文エラー）
git bisect skip 503b47ed2f17b0333e3be4deaccfd6a3d954c026
# fast: [58cb38de908c6f318786a70e77b9bcd2e01d121a] c25: ラベル関数の構文を修正
git bisect fast 58cb38de908c6f318786a70e77b9bcd2e01d121a
# first slow commit: [25862fb984452aeb80baef8dd58f291da3b675f4] c26: 監査ログ用の待機を追加

c24 は py_compile に失敗したので 125 で skip され、隣の c25 で判定が続きました。

skip が続いて絞り切れない場合

原因の候補がすべて skip したコミットに囲まれると、Git は候補を一覧で示して止まります。c22 を good、c25 を bad として、c24 と c23 を手で skip した例です。

git bisect start HEAD~5 HEAD~8
git bisect skip
git bisect skip

Bisecting: 0 revisions left to test after this (roughly 1 step)
[a6b4f579a4a4982c7ca4bb368d7ed53d4a10e961] c23: ラベル関数を追加（書きかけ）
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
503b47ed2f17b0333e3be4deaccfd6a3d954c026
a6b4f579a4a4982c7ca4bb368d7ed53d4a10e961
58cb38de908c6f318786a70e77b9bcd2e01d121a
We cannot bisect more!

この場合は、候補の数コミットを git show で読んで判断します。 ビルドできないコミットが続く区間では、そのコミットだけ一時的にパッチを当てて判定する方法もあります（判定後は git checkout -- . などで戻します）。

--term-old・--term-newで「遅くなった」を探す

bisect は不具合探しだけでなく、「いつから遅くなったか」「いつから直ったか」のような変化にも使えます。 good / bad という言葉が合わないときは、用語を自分で決められます。

#!/usr/bin/env bash
# ../check_speed.sh：ビルド不可は 125、0.2秒以上なら 1（new = slow）、それ未満なら 0（old = fast）
python3 -m py_compile ./*.py 2>/dev/null || exit 125
python3 - <<'PY'
import time, sys
from stock import total
t = time.perf_counter(); total([(1, 1)]); dt = time.perf_counter() - t
print(f"{dt:.3f}s")
sys.exit(1 if dt >= 0.2 else 0)
PY

git bisect start --term-old=fast --term-new=slow
git bisect slow
git bisect fast HEAD~10
git bisect terms
git bisect run ../check_speed.sh

status: waiting for both good and bad commits
status: waiting for good commit(s), bad commit known
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[58cb38de908c6f318786a70e77b9bcd2e01d121a] c25: ラベル関数の構文を修正
Your current terms are fast for the old state
and slow for the new state.
running '../check_speed.sh'
0.000s
Bisecting: 2 revisions left to test after this (roughly 1 step)
[d028497602b87a7603bb19c8d77b186ab5ba602c] c27: 小さな変更
running '../check_speed.sh'
0.300s
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[25862fb984452aeb80baef8dd58f291da3b675f4] c26: 監査ログ用の待機を追加
running '../check_speed.sh'
0.300s
25862fb984452aeb80baef8dd58f291da3b675f4 is the first slow commit

表示が「first slow commit」になり、c26 で time.sleep(0.3) が入ったとわかりました。

「いつ直ったか」を探すときに good / bad のまま使うと、意味が逆になって混乱しがちです。 用語を変えると、git bisect fixed のように自然に答えられます。git bisect run では、old が終了コード 0、new が 1 です。

log・replay・visualizeで判定を見直す

visualize：残りの候補を見る

git bisect visualize --oneline   # git bisect view でも同じ

c15 を bad と答えた直後の表示です（GUI の無い環境では git log で表示されます）。

567b972 c15: 小さな変更
99582f7 c14: 小さな変更
6ba85b6 c13: 小さな変更
...
657aafc c03: 小さな変更
143b8a3 c02: 小さな変更

replay：答え間違いを直してやり直す

good と bad を答え間違えても、最初からやり直す必要はありません。 log を保存して、間違えた行を直し、replay します。c15（正常）を間違えて bad と答えた例です。

git bisect start HEAD v1.0
git bisect bad                    # c15 を間違えて bad に
git bisect log > ../bisect.log
git bisect reset
sed -i "s/^git bisect bad 567b/git bisect good 567b/" ../bisect.log
git bisect replay ../bisect.log

Bisecting: 6 revisions left to test after this (roughly 3 steps)
[874e37dfc68e5b28c7629757c9caa3893fb75605] c08: 小さな変更

修正後の bisect.log（コメント行を除く）と replay の結果です。

git bisect start 'HEAD' 'v1.0'
git bisect good 567b9729d30e51bfe8a63881d3961fccc55bb607

We are not bisecting.
Bisecting: 14 revisions left to test after this (roughly 4 steps)
[567b9729d30e51bfe8a63881d3961fccc55bb607] c15: 小さな変更
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[208945a302dc529ab54dd47839bf973a8f2e3f06] c22: 小さな変更

間違えたまま進むと c08 方向（原因の無い側）を探してしまいますが、replay 後は正しく c22 に進みました。 結果に違和感があったら、まず git bisect log で答えを見直すのが近道です。

--first-parentでマージ単位に探す

ブランチをマージで取り込む運用では、--first-parent を付けると「どのマージで不具合が入ったか」を探せます。 feature ブランチの2つ目のコミット（f2）で不具合が入り、それを main にマージした履歴です。

* cb03673 m4: 次の変更
*   bddcc9e Merge branch 'feature/discount'
|\
| * 33cf3ca f3: 割引の表示
| * af16b57 f2: 割引計算を追加
| * d809f22 f1: 割引の下準備
* | 8178936 m3: 別の変更
|/
* de90de0 m2: 準備
* 0919ced m1: 在庫合計

--first-parent 側のログです。

Bisecting: 0 revisions left to test after this (roughly 1 step)
[bddcc9ecf787ec9b38b6ab44355d48752d01afa9] Merge branch 'feature/discount'
running 'sh' '-c' 'python3 test_stock.py 2>/dev/null'
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[81789360b731f267f4540b9af7ce83fc6aba618a] m3: 別の変更
running 'sh' '-c' 'python3 test_stock.py 2>/dev/null'
bddcc9ecf787ec9b38b6ab44355d48752d01afa9 is the first bad commit
Merge: 8178936 33cf3ca
    Merge branch 'feature/discount'

通常は feature 内のコミットまで降りて探し、--first-parent は main の流れ（マージコミットの1つ目の親）だけをたどります。 「どの PR で入ったか」をまず知りたい、feature 内のコミットがビルドできないことが多い、といった場合に便利です。

探索回数の目安と使いどころ

二分探索なので、確認する回数はおおよそ log2(候補のコミット数) 回です。

今回の30コミットでも、手動・自動とも5回の判定で特定できました。

使える場面・使いにくい場面

つまずきと対処

未コミットの変更がある状態で start した例です。探索は始まらず、元のブランチのままでした。

Bisecting: 14 revisions left to test after this (roughly 4 steps)
error: Your local changes to the following files would be overwritten by checkout:
    stock.py
Please commit your changes or stash them before you switch branches.
Aborting

bisect 中かどうかわからなくなったら、git status を見ます。

HEAD detached at 567b972
You are currently bisecting, started from branch 'main'.
  (use "git bisect reset" to get back to the original branch)

git bisect reset を実行すると、開始前の main に戻ります。

Previous HEAD position was 567b972 c15: 小さな変更
Switched to branch 'main'

よくある質問

Q. good のコミットはどうやって決めればよいですか？ A. 「この時点では動いていた」と確実にわかるタグやリリースを選ぶのが簡単です。わからない場合は、少し古いタグをチェックアウトしてテストし、正常なものを探してから start します。

Q. bisect 中に見つけた不具合をその場で直してよいですか？ A. bisect 中は過去のコミットを見ているだけなので、直すのは git bisect reset で戻ってからにします。原因のコミットがわかれば、git revert や修正コミットで対応できます。

Q. テストが無いリポジトリでも使えますか？ A. 使えます。 手動で動かして目で確認し、good / bad を答えれば十分です。繰り返し確認するなら、その確認を短いスクリプトにして git bisect run に渡すと楽になります。

Q. 判定スクリプトはどこに置けばよいですか？ A. リポジトリの外（../check.sh など）に置きます。 リポジトリ内に置くと、そのファイルが無い古いコミットでは実行できず、bogus exit code 127 で止まります。

まとめ

• git bisect は good と bad の間を二分探索し、不具合が最初に入ったコミットを特定します。30コミットなら約5回の確認で済みます。
• 手動は start → bad → good → 答えを繰り返す → reset。git bisect start <bad> <good> で1行にまとめられます。
• git bisect run は終了コードで判定：0 が good、1〜127（125 除く）が bad、125 が skip、128 以上で中断。
• ビルドできないコミットは skip（run では 125）。候補が skip ばかりになったら一覧から読んで判断します。
• --term-old / --term-new で「遅くなった」「直った」も探せます。
• 答え間違いは git bisect log → 編集 → replay、マージ単位で探すなら --first-parent を使います。
• 判定スクリプトはリポジトリの外に置き、終わったら必ず git bisect reset で戻ります。

株式会社RJCでは、git bisectのような原因調査の手順を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。