《使用 Git 进行版本控制》第三版

第 8 章 查找提交 查找提交

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

一个好的版本控制系统应支持 "考古学 "和 调查版本库。Git 提供了多种机制来帮助你查找符合特定条件的提交。

在本章中，我们将向你传授查找特定提交及其元数据的技巧。我们将重点介绍三种可以用来搜索版本库提交历史的方法。第一种方法非常强大，有助于找到符合搜索条件的单个提交。第二种方法可提供对文件进行修改的提交信息，第三种方法则使用常规git log 命令的特定搜索变体。

本章除了让你掌握 Git 搜索提交的技巧外，还为第九章做了铺垫，在第九章中，我们将深入探讨如何修改找到的提交。

使用 Git bisect

git bisect 命令是一个功能强大的 工具，用于根据任意搜索条件隔离特定提交。它非常适合当你发现 "错误 "或 "糟糕 "的东西正在影响你的版本库，而你知道代码一直都很好的情况。例如，假设你正在开发 Linux 内核，测试启动失败了，但你确信启动在更早的某个时候成功了，也许是在上周或之前的某个版本标签上。在这种情况下，您的版本库已经从已知的 "好 "状态过渡到了已知的 "坏 "状态。

但这种转变是何时发生的？是哪个提交导致了它的中断？git bisect 正是用来帮助您回答这个问题的。

唯一真正的搜索要求是，在给定版本库的签出状态时，你能够确定它是否满足搜索要求。在这种情况下，你必须能够回答 "已签出内核的版本是否能构建和启动？在开始之前，你还必须知道提交的好版本和坏版本，这样搜索才会有界限。简而言之，你不应该在搜索需求中提供不正确的提交范围。

git bisect 命令在执行时会在内部应用二进制搜索算法；该命令会系统地在一个不断缩小的范围内选择新的提交，该范围的一端是良好行为，另一端是不良行为。最终，这个不断缩小的范围将精确定位引入错误行为的提交。图 8-1提供了这一概念的总体视图。

图 8-1. Git 分段范围修订概念

在bisect 模式下，您只需提供初始好坏提交，然后反复回答 "此版本是否有效 "的问题即可。

首先，您需要确定一个好的提交和一个坏的提交。在实践中，坏版本通常是您当前的HEAD ，因为当您突然发现有问题或被分配了一个要修复的 bug 时，您就是在这个版本上工作的。

要找到一个初始的好版本可能有点困难，因为它通常埋藏在历史记录的某个地方。你也许能说出或猜出版本库历史中某个你知道能正确运行的版本。这可能是一个有标签的发布版本，如v2.6.25 ，也可能是main 分支上 100 次修订前的某个提交，如main~100 。理想情况下，它应与你的错误提交相近（main~25 比main~100 好），而且不要埋藏得太深。无论如何，您都需要知道或能够验证它实际上是一个好的提交。

您必须从一个干净的工作目录启动git bisect 进程 ，而且您的工作目录必须指向项目的顶级目录。进程必然会调整工作目录，以包含不同版本的版本库。从一个不干净的工作空间开始是自找麻烦；你的工作目录很容易丢失。如果你有任何工作变更，可以暂时将其隐藏起来。我们将在第 10 章讨论暂存问题。

以克隆 Linux 内核为例，让我们告诉 Git 开始搜索：

    $ cd linux-2.6
    $ git bisect ...