git-bisect - クラウドでオンライン

プログラム：

NAME

git-bisect - バイナリ検索を使用してバグを引き起こしたコミットを見つける

SYNOPSIS

git 二等分

DESCRIPTION

このコマンドはさまざまなサブコマンドを使用し、サブコマンドに応じて異なるオプションを使用します。

git bisect start [--term-{old,good}= --term-{新しい、悪い}= 】
[--チェックアウトなし] [ [ ...]] [--] [ ...]
git bisect (悪い|新しい) [ 】
git bisect (古き|古い) [ ...]
git bisect 用語 [--term-good | --用語が悪い]
git bisect スキップ [( | )...]
git bisect リセット [ ]
git bisect Visual
git bisect リプレイ
git bisect ログ
git bisect 実行...
git bisect ヘルプ

このコマンドは、バイナリ検索アルゴリズムを使用して、プロジェクトの履歴内のどのコミットを見つけますか
バグを導入しました。 これを使用するには、最初に、次のものが含まれていることがわかっている「悪い」コミットを指定します。
バグと、バグが導入される前に知られている「良好な」コミットです。 次に、git
bisect は、これら XNUMX つのエンドポイント間のコミットを選択し、選択されたコミットが正しいかどうかを尋ねます。
「良い」か「悪い」かです。 正確なコミットが見つかるまで範囲を絞り続けます。
それが変化をもたらしました。

実際、 git bisect を使用すると、変更されたコミットを見つけることができます。 どれか あなたの財産
プロジェクト; 例: バグを修正したコミット、またはベンチマークの原因となったコミット
向上するパフォーマンス。 このより一般的な用法をサポートするために、「古い」と「新しい」という用語は次のようになります。
「良い」と「悪い」の代わりに「」を使用することも、独自の用語を選択することもできます。 セクションを参照
詳細については、以下の「代替用語」を参照してください。

Basic 二等分 始めて、 悪い、 良い
例として、以前の機能を壊したコミットを見つけようとしているとします。
プロジェクトのバージョン v2.6.13-rc2 で動作することがわかっています。 二分セッションを次のように開始します。
以下：

$ git 二分開始
$ git bisect bad # 現在のバージョンは不正です
$ git bisect Good v2.6.13-rc2 # v2.6.13-rc2 は良好であることが知られています

少なくとも XNUMX つの悪いコミットと XNUMX つの良いコミットを指定すると、git bisect はコミットを選択します。
その範囲の履歴の真ん中でそれをチェックアウトし、次のようなものを出力します。
以下

二等分: この後テストする必要があるリビジョンは 675 個残っています (約 10 ステップ)

ここで、チェックアウトしたバージョンをコンパイルしてテストする必要があります。 そのバージョンが動作する場合
正しく入力してください

$ git bisect 良い

そのバージョンが壊れている場合は、次のように入力します

$ git bisect 悪い

次に、 git bisect は次のような応答を返します。

二等分: この後テストする必要があるリビジョンは 337 個残っています (約 9 ステップ)

プロセスを繰り返します。ツリーをコンパイルし、テストし、それが適切かどうかに応じて判断します。
または、必要な次のコミットを要求するには git bisect Good または git bisect bad を実行します。
テスト。

最終的には検査するリビジョンがなくなり、コマンドが出力されます。
最初の不正なコミットの説明。 参照 refs/bisect/bad は左向きになります
そのコミットで。

バイセクト リセット
二分セッション後、二分状態をクリーンアップして元の HEAD に戻すには、
次のコマンドを発行します。

$ git bisect リセット

デフォルトでは、これにより、ツリーは git の前にチェックアウトされたコミットに戻ります。
二分スタート。 (新しい git bisect start もこれを行います。古い bisection がクリーンアップされます。
州。）

オプションの引数を使用すると、代わりに別のコミットに戻ることができます。

$ git bisect リセット

たとえば、 git bisect replace bisect/bad は最初の不良リビジョンをチェックアウトしますが、 git
bisectリセットHEADは現在の二分化コミットを残し、切り替えを回避します
まったくコミットします。

代替の 条件
破損を引き起こしたコミットではなく、
他の「古い」状態と「新しい」状態の間で変化を引き起こすコミット。 例えば、
特定の修正を導入したコミットを探しているかもしれません。 あるいはあなたもそうかもしれません
ソースコードのファイル名がすべて最終的に変換された最初のコミットを探しています。
会社の命名基準に従ってください。 あるいは何でも。

このような場合、「良い」と「悪い」という用語を使用して「
変更前の状態」と「変更後の状態」です。したがって、代わりに、
「良い」と「悪い」の代わりに、それぞれ「古い」と「新しい」という用語。 (ただし、注意してください。
XNUMX 回のセッションで「良い」と「悪い」、「古い」と「新しい」を混在させることはできません。)

このより一般的な使用法では、「新しい」コミットに何らかのプロパティを持つ git bisect を提供します。
そしてそのプロパティを持たない「古い」コミット。 git bisect がチェックアウトするたびに、
commit する場合は、そのコミットにプロパティがあるかどうかをテストします。 存在する場合は、コミットを「新規」としてマークします。
それ以外の場合は、「古い」とマークします。 二等分が完了すると、git bisect はどれを報告しますか
commit によってプロパティが導入されました。

「良い」と「悪い」の代わりに「古い」と「新しい」を使用するには、 git bisect start を指定せずに実行する必要があります。
commit を引数として指定し、次のコマンドを実行してコミットを追加します。

git bisect 古い [ 】

コミットが求められた変更の前に行われたことを示すため、または

git bisect 新しい [ ...]

後であることを示します。

現在使用されている用語のリマインダーを取得するには、次を使用します。

git bisect 用語

git bisect term --term-old または git を使用すると、古い (それぞれ新しい) 用語だけを取得できます。
二分項 --term-good。

「悪い」/「良い」または「新しい」/「古い」の代わりに独自の用語を使用したい場合は、
任意の名前を選択します (reset、start などの既存の bisect サブコマンドを除く)。
を使用して二等分を開始する

git bisect start --term-old --新しい用語

たとえば、パフォーマンスの低下を引き起こしたコミットを探している場合は、
使うかもしれない

git bisect start --term-old fast --term-new low

または、バグを修正したコミットを探している場合は、次のように使用できます。

git bisect start --term-new 固定 --term-old 壊れた

次に、git bisect を使用しますそしてgit bisect git bisect の代わりに良いものと
git bisect はコミットをマークするには悪いです。

バイセクト 視覚化する
現在残っている容疑者を確認するには ギク、実行中に次のコマンドを発行します。
二等分プロセス:

$ git bisect Visual

view は、visual の同義語としても使用されます。

Status DISPLAY 環境変数が設定されていない、 git ログ 代わりに使用されます。 与えることもできます
-p や --stat などのコマンドライン オプション。

$ git bisect ビュー --stat

バイセクト ログ & 二等分 リプレイ
リビジョンを良好または不良としてマークした後、次のコマンドを発行して、何が変更されたかを表示します。
これまでに行われたこと:

$ git bisect ログ

リビジョンのステータスの指定を間違えたことが判明した場合は、次のことができます。
このコマンドの出力をファイルに保存し、それを編集して間違ったエントリを削除します。
次に、次のコマンドを発行して、修正された状態に戻します。

$ git bisect リセット
$ git bisect そのファイルを再生

回避 テスト a コミット
二分セッションの途中で、提案されたリビジョンが適切ではないことがわかった場合
テストするもの (例: ビルドに失敗しますが、その失敗には何もないことがわかります)
追跡しているバグに対処するため)、近くのコミットを手動で選択してテストできます。
代わりにXNUMXつ。

例：

$ git bisect 良い/悪い # 前回のラウンドは良いか悪いか。
二等分: この後テストする必要があるリビジョンは 337 個残っています (約 9 ステップ)
$ git bisect Visual # おっと、それは面白くありません。
$ git replace --hard HEAD~3 # 何の前に 3 リビジョンを試してください
# 提案されました

次に、選択したリビジョンをコンパイルしてテストし、その後リビジョンを良好または不良としてマークします。
通常の方法で。

バイセクト スキップ
自分で近くのコミットを選択する代わりに、Git にそれを行うよう依頼できます。
コマンドを発行します:

$ git bisect stop # 現在のバージョンはテストできません

ただし、探しているコミットに隣接するコミットをスキップすると、Git は実行できなくなります。
それらのコミットのどれが最初の悪いコミットであったかを正確に知るために。

範囲表記を使用すると、XNUMX つのコミットだけではなく、ある範囲のコミットをスキップすることもできます。
例：

$ git bisect スキップ v2.5..v2.6

これにより、v2.5 以降、v2.6 まではコミットを行わないように bisect プロセスに指示します。
テストされる。

範囲の最初のコミットもスキップしたい場合は、
コマンド：

$ git bisect スキップ v2.5 v2.5..v2.6

これにより、v2.5 と v2.6 (両端を含む) の間のコミットが次のように行われる必要があることが bisect プロセスに伝えられます。
スキップしました。

切断 ダウン 二等分 by 与え 他には？ パラメータ 〜へ 二等分 start
ツリーのどの部分がわかっていれば、試行回数をさらに減らすことができます。
発行時にパスパラメータを指定することで、追跡している問題に関係している
二分開始コマンド:

$ git bisect start -- Arch/i386 include/asm-i386

複数の適切なコミットが事前にわかっている場合は、次の方法で二分領域を狭めることができます。
を発行するときに、不良コミットの直後に良好なコミットをすべて指定します。
二分化開始コマンド:

$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
# v2.6.20-rc6 が悪い
# v2.6.20-rc4 と v2.6.20-rc1 は良い

バイセクト ラン
現在のソース コードが良いか悪いかを判断できるスクリプトがある場合は、次のことができます。
次のコマンドを発行して二等分します。

$ git bisect run my_script 引数

スクリプト (上記の例では my_script) は、次の場合にコード 0 で終了する必要があることに注意してください。
現在のソース コードは良好/古いため、1 ～ 127 (両端を含む) のコードで終了します。
現在のソースコードが不良または新しい場合は 125 を除きます。

それ以外の終了コードを指定すると、二分化プロセスが中止されます。 注目すべきプログラムは、
exit(-1) で終了すると $? が残ります。 = 255, (「 終了する(3) マニュアルページ)、値は次のようになります。
&0377で切り刻みます。

現在のソース コードをテストできない場合は、特別な終了コード 125 を使用する必要があります。 もし
スクリプトがこのコードで終了すると、現在のリビジョンはスキップされます (「git bisect stop」を参照)
その上）。 125 であるため、この目的で使用する最も適切な値として 126 が選択されました。
および 127 は、特定のエラー ステータスを通知するために POSIX シェルによって使用されます (127 はコマンド用ではありません)
見つかった、126 は見つかったが実行できないコマンドを表します。これらの詳細は重要ではありません。
bisect 実行に関する限り、これはスクリプトの通常のエラーです)。

二分セッション中に、一時的な変更が必要になることがよくあります。
(例: ヘッダー ファイル内の s/#define DEBUG 0/#define DEBUG 1/、または「
このコミットには、この二分化が適用されていない別の問題を回避するために、このパッチを適用する必要があります。
") に興味があります。") がテスト中のリビジョンに適用されます。

このような状況に対処するには、内部の git 二等分 テストする次のリビジョンを見つけます。
スクリプトはコンパイル前にパッチを適用し、実際のテストを実行し、その後で決定することができます。
リビジョン (必要なパッチが適用されている可能性があります) がテストに合格した場合、ツリーを巻き戻します。
元の状態に。 最後に、スクリプトは実際のテストのステータスで終了します。
git bisect run コマンド ループで bisect セッションの最終的な結果を決定させます。

OPTIONS

--チェックアウトなし
二分プロセスの反復ごとに新しい作業ツリーをチェックアウトしないでください。
代わりに、という名前の特別な参照を更新するだけです。 BISECT_HEAD を指すようにする
テストする必要があるコミット。

このオプションは、各ステップで実行するテストが適切でない場合に便利です。
チェックアウトされたツリーが必要です。

リポジトリがベアの場合は、--no-checkout が想定されます。

例

· v1.2 と HEAD の間で壊れたビルドを自動的に二分します。

$ git bisect start HEAD v1.2 -- # HEAD は不良ですが、v1.2 は良好です
$ git bisect run make # "make" でアプリをビルドする
$ git bisect restart # bisect セッションを終了する

· オリジンと HEAD の間でテスト失敗を自動的に二等分します。

$ git bisect start HEAD Origin -- # HEAD は不良ですが、Origin は良好です
$ git bisect run make test # "make test" ビルドとテスト
$ git bisect restart # bisect セッションを終了する

· 壊れたテスト ケースを自動的に二等分します。

$猫 ~/test.sh
#!/bin/sh
|| 作る || exit 125 # これにより壊れたビルドがスキップされます
~/check_test_case.sh # テストケースはパスしますか?
$ git bisect start HEAD HEAD~10 -- # 犯人は最後の 10 人の中にいます
$ git bisect 実行 ~/test.sh
$ git bisect restart # bisect セッションを終了する

ここでは test.sh カスタム スクリプトを使用します。 このスクリプトでは、make が失敗した場合はスキップします。
現在のコミット。 check_test_case.sh は、テスト ケースが合格した場合は 0 で終了し、1 で終了する必要があります。
さもないと。

test.sh と check_test_case.sh の両方をリポジトリの外に置いた方が安全です。
bisect、make、test プロセスとスクリプト間の相互作用を防止します。

· 一時的な変更を加えて自動的に二分します (ホットフィックス):

$猫 ~/test.sh
#!/bin/sh

# ホットフィックスブランチをマージして作業ツリーを微調整します
# そしてビルドを試みます
if git merge --no-commit ホットフィックス &&
make
その後
# プロジェクト固有のテストを実行し、そのステータスを報告する
~/check_test_case.sh
ステータス=$?
ほかに
# これはテスト不可能であることを呼び出し元に伝える
ステータス=125
fi

# 微調整を元に戻して、次のコミットへのクリーンな反転を可能にします
git リセット --hard

# コントロールを返す
$status を終了します

これにより、各テストの実行前にホットフィックス ブランチからの変更が適用されます。
ビルドまたはテスト環境が変更されたため、古いリビジョンには修正が必要になる可能性があります。
新しいものはすでにあります。 (ホットフィックス ブランチがコミットに基づいていることを確認してください。
二等分するすべてのリビジョンに含まれるため、マージは取り込まれません
多すぎるか、git merge の代わりに git Cherry-pick を使用してください。)

· 壊れたテスト ケースを自動的に二等分します。

$ git bisect start HEAD HEAD~10 -- # 犯人は最後の 10 人の中にいます
$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
$ git bisect restart # bisect セッションを終了する

これは、単一のテストでテストを作成する場合、実行スクリプトなしで実行できることを示しています。
ライン。

· 破損したリポジトリ内のオブジェクト グラフの適切な領域を特定します。

$ git bisect start HEAD [ ... ] --チェックアウトなし
$ git bisect run sh -c '
GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) &&
git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ &&
git Pack-objects --stdout >/dev/null
rc=$?
rm -f tmp.$$
テスト $rc = 0'

$ git bisect restart # bisect セッションを終了する

この場合、 git 二等分 ラン 終了すると、bisect/bad は次のコミットを参照します。
到達可能なグラフが必要な意味で完全に走査可能である少なくとも XNUMX つの親
by git パック オブジェクト.

· コード内の回帰ではなく修正を探す

$ git 二分開始
$ git bisect new HEAD # 現在のコミットは新規としてマークされます
$ git bisect old HEAD~10 # 今から XNUMX 番目のコミットは古いとしてマークされます

または：

$ git bisect start --term-old壊れた --term-newfixed
$ git bisect が修正されました
$ git bisect 壊れた HEAD~10

取得 助けます
git bisect を使用して簡単な使用法の説明を取得し、 git bisect help または git bisect -h を使用して、
長い使用法の説明を取得します。

onworks.net サービスを使用してオンラインで git-bisect を使用する