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"文件。提交哈希写入该文件。

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

3.2-stable
3.1-stable
3.0-stable

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

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

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

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

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

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

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

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

$ git bisect bad

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

$ git bisect good

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

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

注解

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