过去3天的某些签到打破了我们的单元测试之一（为什么还不清楚）。
我假设找到哪种签入的最佳方法是从3天前开始在分支中提取代码，验证测试通过，然后在工作之间半途继续进行签入，并且找不到该签入造成了问题。
哪个会引起问题：
如果重要的话，我们通过VSO（现在称为Azure DevOps）使用Git。
谢谢-戴夫
答案 0 :(得分：4)
UPDATE 提供有关如何使用bisect
您所描述的正是git bisect所做的。然后，您所需要做的就是确定一个有效的提交（在引入错误之前）和一个无效的提交（大概是当前的提交）。
现在，bisect的全部要点是发现事情何时最后好（或第一次坏），因为您不知道。因此，当您确定“一个有效的提交”时，稍微更新得更快一些，但这并不重要。 （特别是因为您花费任何时间尝试更精确地设置起始点，所以bisect可能会花费更多时间来更有效地准确地找到引入错误的提交。）
因此，如果您知道一周前，您在本地已在master上检出了良好的（错误前）副本，则可以给
master@{1 week ago}
这依赖于本地刷新日志，因此仅适用于当时签出了良好副本的仓库。如果不可行，您可以使用
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是做到这一点的最佳方法。