はじめに
GitHubでプルリクエスト（PR）をマージする際、「Create a merge commit」「Rebase and merge」「Squash merge」のどちらを選ぶべきか悩んだことはありませんか？
AIにそれぞれのメリット・デメリットを相談してみたところ、メリットの一つとして**「git bisectが使いやすくなる」**というキーワードが出てきました。
今まで使ったことがなかったgit bisectですが、実際にハンズオンを作成して試してみました。
そもそも git bisect とは？
git bisect（ギット・バイセクト）とは、バグが混入したコミットを**二分探索（バイナリサーチ）**で高速に特定するためのGit標準コマンドです。
- 「以前は正常に動いていた」
- 「今の最新版ではバグが出ている」
という状態のときに、「ここまでは確実にOKだった（good）」「ここからはバグっている（bad）」と指示を与えるだけで、Gitが自動的にコミット履歴の中央に移動し、「最初にバグを混入させた犯人のコミット（The first bad commit）」を特定します。
ハンズオン：git bisect を体感してみる
実際に簡単なPythonコードを作成し、故意にバグを混入させた履歴を作って検証しました。
※ Windows環境でPowerShellを使ってファイル生成する際、文字コード（UTF-16）の影響で SyntaxError: source code string cannot contain null bytes が発生するトラブルがあったので、文字コードをUTF-8で明示的に指定して回避しました。
なぜ「Rebase and merge」だと git bisect が強力になるのか？
今回のハンズオンを通して、なぜ「Rebase and merge」が git bisect と相性が良いのか、その理由も体感しました。
① 履歴が「一本道（Linear）」になるから
「Create a merge commit」を多用した入り組んだマージグラフ（トポロジカル構造）だと、二分探索で分岐の途中にチェックアウトされた際、他のブランチの影響でビルドが通らなかったり、意図しないコード状態で判定が難しくなったりすることがあります。
「Rebase and merge」によって履歴が直線状に整列していれば、どのチェックアウトポイントでも確実にビルド・テストが通る状態が保たれやすいです。
② 各コミットの単位がクリアになるから
PRごとにコミットを整理して「Rebase and merge」でマージすると、1コミット＝1つの機能変更という綺麗な単位が保たれるため、git bisect が特定したコミットからの原因調査やコードレビュー（あるいは git revert）が非常に容易になります。
まとめ
-
git bisectは二分探索でバグ混入コミットを爆速で特定できる強力なコマンド - 「Rebase and merge」でクリーンな一本道の履歴を作っておくことで、
git bisectが有効活用できる - PRのマージ戦略を考える際は、単に「見た目がキレイ」というだけでなく、「将来バグが起きたときの調査コストを下げる」という観点を持つことが大切
おわりに
AIには「good / bad」を確認する自動テストを作成する事も補足されていました。（手動での動作確認は大変だなので）
立ち合いたくありませんが、次に「いつの間にか動かなくなっていた」というトラブルに直面した際は、git bisect を試してみたいと思います。
参考（感謝）