Bisecting regressions

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

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

什么是两分法？

Godot开发人员使用 Git 版本控制系统.在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 问题的”预分节”结果,以便其他参与者可以继续从该部分开始参与.

要开始划分,你必须首先确定 “坏” 和 “好” 的版本提交散列值(标识符).”坏” 指的是表现出错误的版本,而 “好” 指的是没有表现出错误的版本.如果你使用一个预发布版本作为 “好” 或 “坏” 下载镜像, 进入包含你下载的预发布版本的文件夹,寻找 README.txt 文件.提交的哈希值就写在该文件中.

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

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

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

使用Git 获取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>`__ .