我有一个很久以前引入过的bug,测试它很痛苦。但是,我强烈怀疑引入该错误的更改发生在一个特定的源代码文件中。
我可以在改变那个文件的提交子集上运行git bisect吗?
答案 0 :(得分:14)
是的,您可以......在联机帮助页中,您可以找到以下内容:
git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<paths>...]
在两个“ - ”之后你放了文件或目录的文件。
示例:
git bisect start -- arch/i386 include/asm-i386 or
答案 1 :(得分:1)
Git bisect允许您避免测试提交(请参阅手册页中的“避免测试提交”):当您进行二等分,并且git选择了一个提交供您测试时,您可以使用{{覆盖它的选择1}}。
使用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)
选择的提交之间没有有趣的提交(即没有修改somepath
的提交),我们可能最终处于循环中。为避免这种情况,我们应该使用条件子句:
git bisect
答案 2 :(得分:0)
一种技术是创建一个临时分支,从一个已知的好位置开始,然后简单地复制到所有位置[即脚本]触摸该文件的提交,然后在该临时分支上进行二等分。这样你就可以跳过所有不相关的提交。
上个月左右在Git邮件列表中对此进行了讨论$gmane/232114。讨论没有确定一个简单的方法来预先跳过没有相关更改的提交(虽然它可能是有用的 - 正如他们所说,欢迎补丁)