标签: git-bisect

我是git的新手,刚刚发现了"git bisect".当您使用新编写的单元测试(事先没有)检查错误时,通常如何使用？

假设我们有一个包含单元测试的存储库,但是 - 经常 - 它们并不完整.在某些版本中,我们发现某个功能无效,但我们知道它之前的某个版本.不幸的是,单元测试未检查该功能.我现在想做的是:

1. 编写测试用例(当然首先失败)
2. 使用此测试用例,使用git bisect查找引入错误的提交
3. 更正错误并提交修复程序(和测试用例)

这个用例有一个问题.由于git bisect检出旧版本,刚插入的测试用例不会出现,所以我不能用它来检查错误.我可以尝试不提交测试,但要将其保持为本地更改.但想象测试文件在某些​​版本之间发生了变化,我可能会遇到合并冲突.

那么该怎么办？git bisect一般是如何使用的？

我倾向于在 git 中广泛使用 bisect 命令。现在我想在 subversion 存储库中执行相同的操作。平分颠覆存储库的最佳方法是什么？

将 svn 存储库转换为 git 不是一种选择，因为它相当大，而且 svn 服务器非常慢 - 转换需要几天时间。

使用git bisect,我们可以放大提交之间可能引入的问题.

我想知道是否还有一种方法可以在一次提交中让git遍历(组合)文件,这样你就可以找出导致问题的文件/部分？

假设我有这些修订：

• rev 1 引入错误 #1
• rev 2 可能会引入错误 #2
• rev 3 可能会引入错误 #2
• rev 4 可能会引入错误 #2
• rev 5 修复错误 #1

要验证错误 #2 发生的位置，需要修复错误 #1。

是否可以在单次git bisect运行期间确定首次出现错误 #2 的修订版，可能通过rev 5在每个二等分步骤中手动应用补丁？手动修补会干扰二等分吗？

我知道,这是可以修复一个git bisect通过会话git bisect log,并git bisect replay在答案中描述了这个问题.

然而,当我搞乱一个bisect会话时,这可能只是一个错误的决定,我希望能够直接修复它(即不会中止整个事情).

例如,我可以想象应该可以rm .git/refs/bisect/good-<hash>撤消错误git bisect good.

这是正确的,还是我错过了什么？
并且,可以对错误进行类似的操作git bisect bad吗？

我知道关于主分支上的所有提交是否应该使项目处于有效的工作状态存在各种观点和哲学.我不是要求这些意见.

为了论证,让我们假设在master分支历史中的某个地方我确定了一个提交,它实际上是一个正在进行的提交,即它不构建或破坏其他东西.由于我们在主分支中讨论历史,因此不能选择重新定位或修改(或实际更改提交的任何内容).

为了警告其他开发人员并使自动git bisect脚本轻松跳过此提交,我想以某种方式将此提交标记为正在进行中.我该怎么做呢？

我已经考虑过使用git tag,但由于标签必须是唯一的,因此我最终会使用标签,就像wip/<some_unique_id>我认为的那样丑陋.另外,从概念上讲,我们不希望将此提交视为标记提交,即我们可能永远不想检查它,我们可能不希望它出现在标记提交点列表等中.

我们的软件是模块化的,我在一个项目中有大约20个git回购.

如果测试失败,有时很难找到匹配的提交,因为有几个开发人员正在处理这20个repos.

我知道测试工作在昨天工作,今天无法接受.

有时我使用git-bisec,但这只适用于一个git repo.

通常两个git repos的更改会导致测试失败.

我可以自己编写一个脏脚本循环遍历我的N git repos,但在此之前,我想知道专家如何解决这个问题.

我使用Python,Django和pytest,但AFAIK这个问题无关紧要.

假设补丁是从过去的特定提交创建的，并且不再适用于HEAD。

我如何找到HEAD历史记录中的第一个提交或更好的最后一个提交，在此补丁中加上“ git apply”？也许有git bisect吗？但是哪个命令会告诉我是否有补丁？

理想情况下，除非有冲突，否则我想返回到该提交，应用补丁，然后基于原始HEAD或与之合并，然后再次进行比较以创建新补丁。在此之后，我想回到原始的HEAD，以便可以继续安装更多补丁。

背景：有许多补丁需要重新发布...（是的，在某些生态系统中，补丁仍然很重要。）

我正在对oh-my-git进行一些个人修改(显示终端上的git状态),我想显示当前bisect的"状态".具体来说,我想获得剩余提交的数量和最后一个bisect命令的大致步骤数,例如:

Bisecting: 9 revisions left to test after this (roughly 3 steps)

似乎获取此信息的唯一方法是通过实际执行git bisect good或git bisect bad.但是,我不想通过运行这些命令中的任何一个来更改repo的状态 - 我只想获取当前的bisect状态.

我正在尝试在我正在处理的应用程序中找到问题,我开始做一个git bisect.bisect有9个步骤,因此256个提交可能会导致此问题.

但是,其中一个git bisect步骤检出了一个无法构建的提交.因为它是在运行之前提交的而不是修复的.下一次提交修复了构建问题.

是否可以将git bisect移动到下一个提交,然后继续运行git bisect？