0

我在工作中遇到了一个情况,我们有一个 git repo,有大约 80 个活跃用户在工作。在修改文件的功能分支上有一个提交 #1。分支合并到master。一段时间后,我发现 master 上缺少由 commit #1 引入的更改。因此,我git bisect将提交 #1 指向好,而当前的 master 则指向坏。

经过一些步骤后,git bisect 发现要归咎于损失的提交是几个月前在另一个功能分支上的一些提交,涉及完全不同的代码区域。

我一次又一次地跑这个平分。我也要求我的同事这样做。每次相同的提交都出来了。

我们无法解释这种行为。手动调查历史记录和文件更改非常困难,因为历史记录非常庞大,分支之间有许多合并。

最近我的同事在另一个代码区域中遇到了另一个丢失的代码的类似问题。再次 bisect 归咎于不相关的提交。

我完全不知道发生了什么。

4

1 回答 1

0

Git bisect 旨在查找单步更改,而不是瞬时更改。

在许多简单的情况下,可以设置开始-结束范围,以便将瞬态变化转换为阶跃变化,但在复杂的合并模式中,普通的开始-结束不起作用。

git bisect给定一个范围时,它还会确定一组合适的基本提交,以便它可以创建一个平分搜索。(IIUC) 这些可以早于给定的起点并且在另一个分支上。可以添加附加(IIRC)“好”点以确保好坏削减倾向于正确的提交。

为什么不也试试git blame

于 2019-12-01T20:33:53.200 回答