Bisecting regressions

平分是在软件中查找回归的一种方法。在GitHub <https://github.com/godotengine/godot>`__上的`Godot存储库中报告了一个错误之后，贡献者可能会要求您“将内容” * bisect *。两分法使贡献者可以更快地修复错误，因为他们可以提前知道是哪个提交导致了回归。您的努力将受到广泛赞赏：)

以下指南说明了如何通过二等分查找回归。

What is bisecting?

Godot开发人员使用`Git <https://git-scm.com/>`__版本控制系统。在Git的上下文中，二等分是执行手动“二进制搜索”的过程，以确定什么时候出现了回归。“ https://en.wikipedia.org/wiki/Binary_search_algorithm>`__尽管它通常用于错误，但也可以用于查找其他种类的意外更改，例如性能下降。

使用官方版本加快平分

在使用Git的``bisect’’命令之前，我们强烈建议尝试使用较旧的（或较新的）正式版本重现该错误。这大大减少了可能需要从源构建和测试的提交范围。您可以在此处<https://downloads.tuxfamily.org/godotengine/>`__找到官方发行版的二进制文件以及alpha，beta和发行候选文件。

例如，如果您已报告针对Godot 3.2的错误，则应首先尝试重现Godot 3.1中的错误（不是补丁程序版本，原因请参见下文）。如果那里没有发生该错误，请尝试在Godot 3.2 * beta 1 *中重现该错误（大约在所有可用测试版本的中间）。如果您无法使用Godot 3.2 beta 1重现该错误，请尝试使用较新的beta和RC版本。如果您确实设法用Godot 3.2 beta 1重现了该错误，请尝试使用较早的alpha版本。

警告

对于二等分回归，请勿使用修补程序版本，例如Godot 3.1.2。而是使用次要版本的第一个发行版，例如Godot 3.1。这是因为修补程序版本是从单独的* stable分支*构建的。这种分支没有遵循Godot的其余开发，而是在“ master”分支中完成的。

Git bisect命令

如果您发现在上述测试过程中未显示该错误的构建，则可以立即将回归二等分。 Git版本控制系统为此提供了一个内置命令：git bisect。这使过程成为半自动化的过程，因为您只需要构建引擎，运行它并尝试重现该错误即可。

注解

在平分回归之前，您需要设置一个构建环境以从源代码编译Godot。为此，请阅读目标平台的：ref：`Compiling <toc-devel-compiling>`页面。 （从源代码编译Godot不需要C ++编程知识。）

请注意，编译 Godot 可能需要在缓慢的硬件上一段时间（在缓慢的双核 CPU 上，每次完全重建需要一个小时）。这意味着整个过程最多可能需要几个小时。如果您的硬件太慢，您可能希望停止并报告 GitHub 问题的”预分节”结果，以便其他参与者可以继续从该部分开始参与。

要开始分一元化，必须首先确定”坏”和”良好”生成中的提交哈希（标识符）。”坏”是指显示 Bug 的生成，而”好”是指不显示 Bug 的版本。如果您使用预发布版本作为”好”或”坏”版本，请浏览”下载镜像 _https：//下载.tuxfamily.org/godotengine/_“*，转到包含您下载的预发布版本的文件夹，并查找”README.txt”文件。提交哈希写入该文件。

如果您使用稳定版本作为“好”或“坏”版本，请根据版本使用以下提交哈希之一：

  1. 3.2-stable
  2. 3.1-stable
  3. 3.0-stable

要引用master分支的最新状态，可以使用“ master”代替提交哈希。

使用Git <doc_getting_source>`获取Godot的源代码。完成此操作后，在终端窗口中，使用cd进入Godot存储库文件夹并输入以下命令：

  1. # <good commit hash> is hash of the build that works as expected.
  2. # <bad commit hash> is hash of the build exhibiting the bug.
  3. $ git bisect start
  4. $ git bisect good <good commit hash>
  5. $ git bisect bad <bad commit hash>

编译Godot。这假定您已设置一个生成环境：

  1. # <platform> is the platform you're targeting for regression testing,
  2. # like "windows", "x11" or "osx".
  3. $ scons platform=<platform> -j4

由于构建Godot需要一些时间，因此您希望为任务分配尽可能多的CPU线程。这就是-j参数的作用。在此，该命令分配4个CPU线程来编译Godot。

运行位于``bin /``文件夹中的二进制文件并尝试重现该错误。

如果构建“仍然”显示错误，请运行以下命令：

  1. $ git bisect bad

如果构建**没有**显示错误，请运行以下命令：

  1. $ git bisect good

输入上述命令之一后，Git 将切换到其他提交。现在，您应该再次构建 Godot，尝试重现 Bug，然后根据结果输入”git 一部分好”或”git 一次坏”。你必须重复几次。提交范围越长，所需的步骤就越多。5 到 10 个步骤通常足以查找大多数回归;Git 将提醒您剩余步骤数（在最坏的情况下）。

完成足够的步骤后，Git将在出现回归的位置显示提交哈希。将此提交哈希值写成对一分为二的GitHub问题的评论。这将有助于解决问题。再次感谢您对Godot的贡献：）

注解

您可以在``git bisect’’上阅读完整文档，这里<https://git-scm.com/docs/git-bisect>`__。