【发布时间】:2013-12-12 23:31:30
【问题描述】:
在我目前正在进行的一个项目中,我们将每个功能保留其自己的分支,并在功能准备好时将其合并回主控。每个功能分支内的提交可能包括大量“WIP”和破坏其他功能的功能,直到它完整且稳定为止。
无论如何,由于主分支的提交是唯一(据说)稳定的提交,我只想在那个分支上git bisect。
有没有办法将git bisect 限制在一个分支上?
【问题讨论】:
标签: git version-control git-bisect
在我目前正在进行的一个项目中,我们将每个功能保留其自己的分支,并在功能准备好时将其合并回主控。每个功能分支内的提交可能包括大量“WIP”和破坏其他功能的功能,直到它完整且稳定为止。
无论如何,由于主分支的提交是唯一(据说)稳定的提交,我只想在那个分支上git bisect。
有没有办法将git bisect 限制在一个分支上?
【问题讨论】:
标签: git version-control git-bisect
如果没有进一步的工作,就没有简单的方法来实现这一点。在玩了一会儿之后,我有一些东西可以帮助你。
git bisect start master f9d5924
for rev in $(git rev-list f9d5924..master --merges --first-parent); do
git rev-list $rev^2 --not $rev^
done | xargs git bisect skip
这以 git bisect 开头,f9d5924 作为你的好提交,master 作为你的坏提交。然后它找到每个合并提交右侧的祖先,而不是在左侧。它将这些祖先传递给git bisect skip 以跳过它们。但是,当它确定哪个提交是错误的时,它将显示来自错误合并提交的所有可能跳过的提交。像下面这样
$ git bisect good
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
0622204625d8817c5d8fd1a2a68b3aa91f2dcdf9
0c771566b9e77e3bdc0a66a7404c8eae9f321a68
5098b44f43f84b213eaab110073a6acd26a5cc02
8b05a808d5e15852fbddaa529ba241fdac8ff693
b0c755c3fa57e3c8d527e76fae38bc9925c01353
We cannot bisect more!
在这种情况下,b0c755c3fa57e3c8d527e76fae38bc9925c01353 是它失败的合并提交。
注意:如果您有章鱼合并(将两个以上分支合并在一起的合并),这将不起作用。
【讨论】:
git bisect 需要一个--first-parent 标志,并在其所需要的帮助下进行描述。它只会遍历实际分支的提交和合并提交,而不是其合并的分支或分支气泡。你要么在你的分支上找到提交,依偎在其他人之间,要么你完成了一个合并提交,并且知道问题出在那个时候合并的分支中的某个地方。
我认为带有--no-parent 标志的git bisect 可以轻松做到这一点,但它不存在。
我唯一能想到的就是在新分支中重新创建分支提交。这是 Linux shell 中的一个示例:
$ git branch bisecttemp <first>
$ for h in `git log --oneline --decorate --first-parent --reverse --format=%H <first>..<last>`; do git checkout -f $h; sleep .5; git reset bisecttemp; git commit -am"$h"; git checkout testing; git reset --hard HEAD@{1}; done
这使得我们关心的<first> 提交产生一个 bisecttemp 分支,获取我们关心的范围内的<first> 和<last> 提交之间的哈希列表,访问每个,重置回 bisecttemp在每个分支之后,不更改工作树,提交与它来自的提交的哈希不同的所有内容,再次检查 bisecttemp,然后将其重置回 head 的最后一个位置,即新提交。
可能有一种更聪明的方法来完成所有这些,但基础是它在我们关心的提交范围的开始处创建一个新分支,然后提交仅分支提交的状态(常规提交并按顺序合并,但不是任何子分支提交)。您不能只在这里挑选樱桃,因为樱桃挑选会查看父母,这会在合并提交时失败。
这没有经过真正的测试,并且可能都是错误的。这只是一个想法。它可以全部汇总到一个接受一系列提交的函数中。
【讨论】:
在一个分支上使用 git bisect 而不签出到 master:
在您要测试的分支上。
git bisect start --no-checkout
这将仅在当前分支上开始平分
像往常一样继续你的平分。
【讨论】:
我也想要一个适当的本地 git 解决方案来解决这个问题,只检查单个分支上的提交,从而“指责”整个合并和/或拉取请求。然而:
由于主分支的提交是唯一(据说)稳定的,我只想在那个分支上 git bisect。
如果提示这个问题的问题是您获得的某些提交被破坏并且您无法测试,您可以使用:
git bisect skip
完全跳过该提交并检查其他提交。这将解决您在提交中断时遇到的问题。找到破坏该功能的提交后,您可以将其合并到您正在跟踪的分支中。
我想您甚至可以通过手动检查或通过脚本来git bisect skip ALL 未合并的提交。这将给出问题中提出的行为。
【讨论】: