过去3天的一些检查打破了我们的一个单元测试（为什么一点也不清楚）。
我假设最好的方法是找到哪个签入是在3天前拉动分支中的代码，验证测试通过，然后继续拉动工作之间的签到并且找不到导致问题的签到。
这导致了问题：
如果重要的话，我们通过VSO（现在的Azure DevOps）使用Git。
谢谢 - 戴夫
更新以提供有关如何使用bisect的更多信息
你所描述的正是git bisect所做的。然后你需要的只是确定一个工作提交（在引入错误之前）和一个损坏的提交（可能是当前的提交）。
现在，bisect的全部意义在于找到事情最后好的（或者先坏的），因为你不知道。因此，当您确定“一个工作提交”时，让它更新近会更快，但不够重要。 （特别是因为任何时候你花费更多的时间来设置起始点，是时候可以更有效地找到错误引入的提交。）
因此，如果你知道一周前，你在本地有一个好的（虫前）副本检查主人，你可以给
master@{1 week ago}
这依赖于本地reflog，因此只能在当时检出好副本的仓库中运行。如果这不实用，你可以使用
git rev-list --until='1 week ago' -n1 master
至少1周前创建最后一次提交（根据提交元数据）。所以像
git bisect start $(git rev-list --until='1 week ago' -n1 master) master
对于上述任何一种表示法，您可以使用3 days而不是1 week，它会稍微提高效率 - 也就是说，在确定错误之前，您可能会减少1或2次搜索。
因此，如果您不确定，尝试预先测试提交是否存在错误并没有太多价值;你只需使用较旧的提交即可。但是如果出于任何原因你真的想要，你可以使用相同的符号来检查给定时间的提交，然后根据你的喜好进行测试。
除了一点，但要注意 - 现在很流行的做法是通过在将每个分支整合到主线之前重新定位每个分支来制作“更清晰”的历史。虽然这些“更干净”的历史确实更加线性和简单，但实际上它们更可能是脏的，因为它们包含从未经过测试的提交。如果其中一个提交由于您的错误以外的原因而发生单元测试失败 - 例如在稍后的提交中被淘汰的合并不一致，那么使用bisect突然不那么容易，因为仅仅是您的单元的绿色/红色状态测试套件不会告诉您是否存在您的错误。
但这对于您一般描述的错误搜索策略（不仅仅是针对bisect）来说也是一个问题。因此，如果通过历史跟踪错误是可行的，那么bisect是最好的方法。