【发布时间】：2020-03-25 15:31:00
【问题描述】：
我在工作中遇到了一个情况，我们有一个 git repo，有大约 80 个活跃用户在工作。
在修改文件的功能分支上有一个提交 #1。分支合并到master。
一段时间后，我发现 master 上缺少由 commit #1 引入的更改。
所以我跑了git bisect，指出提交#1 好，而当前master 不好。
经过一些步骤后，git bisect 发现要归咎于丢失的提交是几个月前在另一个功能分支上的一些提交，涉及完全不同的代码区域。
我一次又一次地跑这个二分法。我也要求我的同事这样做。每次都发出相同的提交。
我们无法解释这种行为。手动调查历史记录和文件更改非常困难，因为历史记录非常庞大，分支之间有许多合并。
最近，我的同事在另一个代码区域的另一段代码丢失时遇到了类似的问题。再次 bisect 归咎于不相关的提交。
我完全不知道发生了什么。
【问题讨论】：
-
您提到在您尝试平分的历史记录中可能有一个或合并提交。你确定你关注的是正确的父母吗？
-
@TimBiegeleisen 我检查的是确保提交 #1 是当前 master 的间接父级。你是这个意思吗？
-
也许不是。 Git bisect 可以追溯到历史并找到事情停止破裂的点。但是如果有合并提交，那么必须有一个步骤告诉 Git 要遵循哪个父级。我建议可能 Git 在合并提交时跟随了错误的父级。
-
@TimBiegeleisen 这很有可能。有很多很多合并。它可能会选择错误的路径。但我不记得 bisect 问我要走哪条路。
-
Bisect，即使在自动运行时，也会留下满满的步骤，您可以从 git bisect log 获取它们并尝试找到您认为出错的那个。
标签： git git-bisect