我有一个很久以前引入的 bug,对它进行测试非常痛苦。然而,我强烈怀疑引入这个 bug 的变更发生在一个特定的源代码文件中。
我能否在修改了该文件的一小部分提交上运行 git bisect?
我有一个很久以前引入的 bug,对它进行测试非常痛苦。然而,我强烈怀疑引入这个 bug 的变更发生在一个特定的源代码文件中。
我能否在修改了该文件的一小部分提交上运行 git bisect?
可以的。在手册中,您会找到这行文字:
git bisect start [--term-{old,good}=<term> --term-{new,bad}=<term>]
[--no-checkout] [<bad> [<good>...]] [--] [<paths>...]
所以在--
之后,您需要输入文件或目录的路径。
例如:
git bisect start -- arch/i386 include/asm-i386
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)
git bisect
选择的提交之间没有有趣的提交(即没有修改somepath
的提交),我们可能会陷入循环。为了避免这种情况,我们应该使用一个条件子句:#!/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
bisect
选择了一个不感兴趣的提交,我们也会立刻跳到最近的“有趣”提交。相反,如果总共有10000个提交,但只有10个提交是重要的,使用 skip
将意味着在访问这些“不重要”的提交时会浪费很多时间。 - Jan Warchoł