13

ずっと前に導入されたバグがあり、それをテストするのは苦痛です。しかし、バグを引き起こす変更が 1 つの特定のソース コード ファイルで行われたのではないかと強く疑っています。

その 1 つのファイルを変更したコミットのサブセットに対して git bisect を実行できますか?

4

3 に答える 3

27

はい、できます。manpageには、次の行があります。

git bisect start [--term-{old,good}=<term> --term-{new,bad}=<term>]
      [--no-checkout] [<bad> [<good>...]] [--] [<paths>...]

の後--に、ファイルまたはディレクトリのパスを入力します。

例えば：

git bisect start -- arch/i386 include/asm-i386
于 2013-09-13T14:29:46.240 に答える
1

Git bisect を使用すると、コミットのテストを回避できます (man ページの「コミットのテストの回避」を参照) git reset --hard <commit you want>。

を使用git logすると、ファイル (またはサブディレクトリ) に影響を与えた最後のコミットを見つけることができます - これはそのハッシュを返します:

git log -1 --pretty=format:%H -- path_that_you_are_interested_in

したがって、テストするコミットが提案されるたびにgit bisect、このコマンドを実行して、影響を受けたコミットのみをテストするようにする必要がありますsomepath。

git reset --hard $(git log -1 --pretty=format:%H -- somepath)

ここで、もう 1 つ注意しなければならないことがあります。somepath最後にチェックされた適切なコミットと によって現在選択されているコミットの間に興味深いコミット (つまり、 を変更するコミット) がない場合git bisect、ループに陥る可能性があります。これを避けるには、条件節を使用する必要があります。

#!/bin/bash

last_good=$(git bisect log | tail -1 | sed 's/git bisect good //')
last_interesting=$(git log -1 --pretty=format:%H -- lily/)

if [ "$last_good" == "$last_interesting" ]; then
    # there are no commits modifying somepath between previously
    # tested and currently checked-out one, so it must be good
    git bisect good
else 
    git reset --hard $(git log -1 --pretty=format:%H -- somepath)
fi
于 2013-09-13T13:15:24.057 に答える
0

1 つの手法は、既知の適切な場所から開始する一時的なブランチを作成し、そのファイルに関係するすべてのコミット (スクリプトなど) を単純にコピーしてから、その一時的なブランチで bisect を実行することです。そうすれば、無関係なコミットをすべてスキップできます。

これは先月ほど$gmane/232114内に Git メーリング リストで議論されました。議論では、関連する変更のないコミットを事前にスキップする簡単な方法は特定されませんでした (パッチは歓迎されると彼らが言うように、おそらく役に立つでしょう)。

于 2013-09-13T13:16:06.887 に答える