乐趣区

关于odoo:Odoo-14开发者指南第二章-管理Odoo服务端实例

jiezi

全书残缺目录请见：Odoo 14 开发者指南（Cookbook）第四版

在第一章 装置 Odoo 开发环境中，咱们学习了如何应用源码中所带的规范外围插件配置 Odoo 实例。本章次要解说如何对 Odoo 实例增加非核心或自定义插件。在 Odoo 中，能够通过多个目录加载插件。此外，举荐应用独自的目录加载第三方插件或自定义的插件，以防止与 Odoo 外围模块产生抵触。甚至 Odoo 企业版也是一种类型的插件目录，须要像加载一般插件目录那样对其进行加载。

本章中，咱们将解说如下内容：

  • 配置插件门路
  • 标准化你的实例目录布局
  • 装置及降级本地插件模块
  • 通过 GitHub 装置插件模块
  • 对插件利用批改
  • 利用及尝试倡议的拉取申请

📝无关用语

本书中，咱们会穿插应用插件 (add-on)、模块(module)、利用(app) 或插件模块(add-on module)。它们都是指可通过用户界面在 Odoo 中装置的 Odoo 利用或扩大利用。

配置插件门路

通过 addons_path 参数的配置，能够在 Odoo 中加载本人的插件模块。在 Odoo 初始化一个新数据库时，它会在 addons_path 配置参数中给定的这些目录中搜寻插件模块。addons_path 会在这些目录中搜寻潜在的插件模块。

addons_path 中所列出的目录预期应蕴含子目录，每个子目录是一个插件模块。在数据库初始化实现后，将可能装置这些目录中所给出的模块。

筹备工作

这一部分假设你曾经筹备好了实例并生成了配置文件，如在第一章 装置 Odoo 开发环境 在一个文件中存储实例配置 一节所形容。Odoo 的源码寄存在~/odoo-dev/odoo 中，而配置文件寄存在~/odoo-dev/myodoo.cfg 中。

如何配置 …

按如下步骤在实例的 addons_path 中增加~/odoo-dev/local-addons 目录：

  1. 编辑你的实例配置文件，即 ~/odoo-dev/myodoo.cfg。

  2. 定位到以 addons_path = 结尾的一行，默认应该会看到如下内容：

    addons_path = ~/odoo-dev/odoo/addons

译者注：以后默认生成的配置文件中为绝对路径

  1. 批改该行，增加一个逗号（英文半角），并接你想想要增加为 addons_path 的目录名称，如以下代码所示：

    addons_path = ~/odoo-dev/odoo/addons,~/odoo-dev/local-addons

  2. 在终端中重启实例

    $ ~/odoo-dev/odoo/odoo-bin -c my-instance.cfg

运行原理 …

在重启 Odoo 时，会读取配置文件。addons_path 变量的值应为一个逗号分隔的目录列表。可承受相对路径，但它们是绝对于当前工作目录的，因而应在配置文件中尽量避免。

至此，咱们仅在 Odoo 中列出了插件目录，但~/odoo-dev/local-addons 中尚不存在插件模块。即便在该目录中新增了插件模块，Odoo 也不会在用户界面中显示这一模块。为此，你须要执行一个额定的操作，在下一部分 更新插件模块列表 中会进行解说。

📝这背地的起因是在初始化新数据库时，Odoo 在可用模块中主动列举了自定义模块，但如若在数据库初始化之后新增模块，就须要像 更新插件模块列表 一节中那样手动更新可用模块列表。

扩大常识 …

在首次调用 odoo-bin 脚本来初始化新数据库时，能够传递一个带逗号分隔目录列表的 –addons-path 命令行参数。这会以所提供插件门路中所找到的所有插件来初始化可用插件模块列表。这么做时，要显式地蕴含根底插件目录（odoo/odoo/addons）以及外围插件目录（odoo/addons）。与后面稍有不同的是本地插件目录不能为空（译者注：请先浏览上面的小贴士），它必须要至多蕴含一个子目录，并蕴含插件模块的最小化构造。

在第三章 创立 Odoo 插件模块中，咱们会来看如何编写你本人的模块。同时，这里有一个生成内容来满足 Odoo 要求的快捷版黑科技：

$ mkdir -p ~/odoo-dev/local-addons/dummy
$ touch ~/odoo-dev/local-addons/dummy/__init__.py
$ echo '{"name":"dummy","installable": False}' > \
~/odoo-dev/local-addons/dummy/__manifest__.py

你能够应用 –save 选项来保留门路至配置文件中：

$ odoo/odoo-bin -d mydatabase \
--addons-path="odoo/odoo/addons,odoo/addons,~/odoo-dev/local-addons" \
--save -c ~/odoo-dev/my-instance.cfg --stop-after-init

本例中，应用相对路径不会有问题，因为它们会在配置文件中转化为绝对路径。

📝注：因为 Odoo 仅当从命令行中设置门路时在插件门路的目录中查看插件，而不是在从配置文件中加载门路的时候，dummy 已不再必要。因而，你能够删除它（或保留到你确定不须要新建一个配置文件时）。

标准化你的实例目录布局

咱们举荐你在开发和生产环境都应用类似的目录布局。这一标准化会在你要执行运维时体现出用途，它也会缓解你日常工作的压力。

这一部分创立将类似生命周期或类似用处的文件分组放在标准化子目录中的目录构造。

📝仅在心愿以类似的文件构造治理开发和生产环境时才须要学习本节。如果不须要，能够跳过本节。

此外，无微妙严格依照本节中雷同的目录构造。请自在依照本人的需要来调整这一构造。

如何标准化 …

创立所举荐实例布局，须要执行如下步骤：

  1. 为每个实例创立一个目录：

    $ mkdir ~/odoo-dev/projectname
$ cd ~/odoo-dev/projectname

  2. 在名为 env/ 的子目录中创立一个 Python 虚拟环境对象：

    $ python3 -m venv env

  3. 创立一些子目录，如下：

    $ mkdir src local bin filestore logs

这些子目录的性能如下：

  • src/：蕴含 Odoo 自身的一个拷贝，以及一些第三方插件我的项目（咱们在下一步中增加了 Odoo 源码）
  • local/：用于保留你针对具体实例的插件
  • bin/：蕴含各类帮忙可执行 shell 脚本
  • filestore/：用于文件存储
  • logs/（可选）：用于存储服务日志文件

  1. 克隆 Odoo 并装置所需依赖包（参见

    第一章 装置 Odoo 开发环境

    获取更多内容）：

    $ git clone -b 14.0 --single-branch --depth 1 https://github.com/odoo/odoo.git src/odoo$ env/bin/pip3 install -r src/odoo/requirements.txt

  2. 以 bin/odoo 保留如下 shell 脚本：

    #!/bin/shROOT=$(dirname $0)/..PYTHON=$ROOT/env/bin/python3ODOO=$ROOT/src/odoo/odoo-bin$PYTHON $ODOO -c $ROOT/projectname.cfg "$@"exit $?

  3. 让该脚本可执行：

    $ chmod +x bin/odoo

  4. 创立一个空的本地模块 dummy：

    $ mkdir -p local/dummy$ touch local/dummy/__init__.py$ echo '{"name":"dummy","installable": False}' >\local/dummy/__manifest__.py

  5. 为你的实例生成配置文件：

    $ bin/odoo --stop-after-init --save \ --addons-path src/odoo/odoo/addons,src/odoo/addons,local \ --data-dir filestore

  6. 增加一个.gitignore 文件，用于通知 GitHub 排除这些给定目录，这样 Git 在提交代码时就会疏忽掉这些目录，例如 filestore/, env/, logs/ 和 src/：

    # dotfiles, with exceptions:.*!.gitignore# python compiled files*.py[co]# emacs backup files*~# not tracked subdirectories/env//src//filestore//logs/

  7. 为这个实例创立一个 Git 仓库并将已增加的文件增加到 Git 中：

    $ git init$ git add .$ git commit -m "initial version of projectname"

运行原理 …

咱们生成了一个有明确标签目录和独立角色的洁净目录构造。咱们应用了不同的目录来存储如下内容：

  • 由其它人所保护的代码（src/ 中）
  • 本地相干的具体代码
  • 实例的文件存储(filestore)

通过为每个我的项目建一个 virtualenv 环境，咱们能够确保该项目标依赖文件不会与其它我的项目的依赖产生抵触，这些我的项目你可能运行着不同的 Odoo 版本或应用了不同的第三方插件模块，这将须要不同版本的 Python 依赖。当然也会带来一部分磁盘空间的开销。

以相似的形式，通过为咱们不同的我的项目应用不同的 Odoo 拷贝以及第三方插件模块，咱们能够让每个我的项目独自的进行演变并仅在须要时在这些实例上装置更新，因而也缩小了引入回退的危险。

bin/odoo 容许咱们不必记住各个门路或激活虚拟环境就能够运行服务。这还为咱们设置了配置文件。你能够在其中增加其它脚本来帮助日常工作。例如，能够增加一个脚本来查看运行实例所需的第三方我的项目。

无关配置文件，咱们仅展现了这里须要设置的最小化选项，但很显著能够做更多设置，例如数据库名、数据库过滤器或我的项目所监听的端口。无关这一话题的更多信息，请参见第一章 装置 Odoo 开发环境。

最初，通过在 Git 仓库中治理所有这些，在不同的电脑上复制这一设置及在团队中分享开发内容变得相当容易。

📝减速贴士

要减速我的项目的创立，能够创立一个蕴含空构造的模板仓库，并为每个新我的项目复制（fork）该仓库。这会省却你从新输出 bin/odoo 脚本、.gitignore 及其它所需模板文件（继续集成配置、README.md、ChangeLog 等等）所破费的工夫。

参见内容

如果你喜爱这种办法，咱们倡议你尝试第三章 服务器部署中的应用 Docker 运行 Odoo 一部分的内容。

扩大常识 …

简单模块的开发要求有各类配置选项，在想要尝试任何配置选项时都会要更新配置文件。更新配置文件经常是一件头痛的事，防止它的一种形式是通过命令行传递所有配置选项，如下：

  1. 手动激活虚拟环境：

    $ source env/bin/activate

  2. 进入 Odoo 源代码目录：

    $ cd src/odoo

  3. 运行服务：

    ./odoo-bin --addons-path=addons,../../local -d test-14 -i account,sale,purchase --log-level=debug

第 3 步中，咱们间接通过命令行传递了一些参数。第一个是 –addons-path，它加载 Odoo 的外围插件目录 addons，以及你本人的插件目录 local，在其中你能够放本人的插件模块。选项 - d 会应用 test-14 数据库或者在该数据库不存在时新建一个数据库。选项 -i 会装置会计、销售和洽购模块。接着，咱们传递了 log-level 选项来将日志级别晋升为 debug，这样日志中会显示更多的信息。

📝通过应用命令行，你能够疾速地批改配置选项。也能够在 Terminal 中查看实时日志。所有可用选项可参见第一章 装置 Odoo 开发环境，或应用 -help 命令来查看所有的选项及各个选项的形容。

装置并降级本地插件模块

Odoo 性能的外围来自于它的插件模块。Odoo 自带的插件是你所领有的财产，同时你也能够从利用商店下载一些插件模块或者本人写插件。

这一节中，咱们将展现如何通过网页界面及命令行来装置和降级插件模块。

对这些操作应用命令行的次要益处有能够同时作用于一个以上的插件以及在装置或降级的过程中能够清晰地浏览到服务端日志，对于开发模式或编写脚本装置实例时都十分有用。

筹备工作

确保你有一个运行中的 Odoo 实例，且数据库已初始化、插件门路已进行失当地设置。在这一部分中，咱们将装置 / 降级一些插件模块。

如何装置降级 …

装置或降级插件有两种办法 - 能够应用网页界面或命令行。

通过网页界面

可依照如下步骤来应用网页界面装置新的插件模块到数据库中：

  1. 应用管理员账户连贯实例并关上 Apps 菜单
    图 2.1 – Odoo 利用列表

  2. 应用搜寻框来定位你想要装置的插件。这里有一些帮忙你实现该工作的操作指南：

    • 激活 Not Installed 过滤器
    • 如果你要查找一个具体的性能插件而不是宽泛的性能插件，删除 Apps 过滤器
    • 在搜寻框中输出模块名的一部分并应用它来作为模块过滤器
    • 你会发现应用列表视图能够浏览到更多的信息
  3. 点击卡片中模块名下的 Install 按钮。

留神有些 Odoo 插件模块具备内部 Python 依赖，如果你的零碎中未装置该 Python 依赖，那么 Odoo 会停止装置并显示如下的对话框：

图 2.2 – 内部库依赖的正告
译者注：按失常装置不会呈现一谬误，需通过 pip uninstall pyldap 能力复现这一谬误

修复这一问题，仅需在你的零碎中装置相干的 Python 依赖即可。

要降级已装置到数据库的模块，应用如下步骤：

  1. 应用管理员账户连贯到实例
  2. 关上 Apps 菜单
  3. 点击 Apps:

    图 2.3 – Odoo 利用列表

  4. 应用搜寻框来定位你所装置的插件。有如下的小贴士：

    • 激活 Installed 过滤器
    • 如果你要查找一个具体的性能插件而不是狭义的性能插件，删除 Apps 过滤器
    • 在搜寻框中输出局部插件模块的名称并按下 Enter 来应用它作为模块过滤器。例如，输出 CRM 并按下 Enter 来搜寻 CRM 利用
    • 你会发现应用列表视图能够浏览到更多的信息
  5. 点击卡片右上角的的三个点，而后点击 Upgrade 选项：

图 2.4 – 降级模块的下拉链接

激活开发者模式来查看模块的技术名称。如果你不晓得如何激活开发者模式，请参见第一章 装置 Odoo 开发环境：

图 2.5 – 利用的技术名称

在激活开发者模式之后，它会以红色显示模块的技术名称。如果你应用的是 Odoo 社区版，会看到一些带有 Upgrade 按钮的利用。这些是 Odoo 企业版的利用，要想装置 / 应用它们，须要购买一个证书。

通过命令行

在数据库中装置新插件，可执行如下步骤：

  1. 查找插件的名称。这是蕴含__manifest__.py 文件的目录名，不带后面的门路。
  2. 进行实例。如果你在操作生产数据库，请进行备份。

  3. 运行如下命令：

    $ odoo/odoo-bin -c instance.cfg -d dbname -i addon1,addon2 --stop-after-init

如果在配置文件中进行过设置能够省略掉 -d dbname。
译者注：请将 addon1,addon2 替换为你所要装置的插件名

  1. 重启实例

降级数据库中已装置的插件，可执行如下步骤：

  1. 查找待更新的插件模块名称。这是蕴含__manifest__.py 文件的目录名，不带后面的门路。
  2. 进行实例。如果你在操作生产数据库，请进行备份。

  3. 运行如下命令：

    $ odoo/odoo-bin -c instance.cfg -d dbname - u addon1 --stop-after-init

如果在配置文件中进行过设置能够省略掉 -d dbname。

  1. 重启实例

运行原理 …

插件模块的装置和降级是两个严密关联的操作，但有一些重要的区别，在上面两局部中进行了强调：

插件装置

在装置插件时，Odoo 以提供的名称查看它的可用插件列表中未装置插件。它还会查看该插件的依赖，并且如果有依赖的话，它会在装置插件前递归装置这些依赖。

单个模块的装置蕴含如下步骤：

  1. 如果存在，运行插件 preinit 钩子
  2. 从 Python 源代码中加载模型定义并在必要时更新数据库构造（参见第四章 利用模型理解更多信息）
  3. 加载插件的数据文件并在必要时更新数据库内容（参见第六章 治理模块数据理解更多信息）
  4. 如果实例中启用了演示数据则装置插件演示数据
  5. 如果存在，运行插件 postinit 钩子
  6. 运行对插件视图定义的验证
  7. 如果启用了演示数据及测试，运行该插件的测试（参见第十八章 自动化测试用例理解更多信息）
  8. 在数据库中更新模块状态
  9. 从插件的翻译文件中更新数据库中的翻译（参见第十一章 国际化理解更多信息）

📝preinit 和 postinit 钩子别离应用 pre_init_hook 和 post_init_hook 键名在__manifest__.py 文件中定义。这些钩子用于在插件模块的装置之前及之后触发 Python 函数。参见第三章 创立 Odoo 插件模块理解更多无关 init 钩子的常识。

插件降级

降级插件时，Odoo 以给定的名称在可用的插件模块列表中查看已装置插件。它还会查看该插件的反向依赖（即依赖于所降级插件的那些插件）。如果存在，则也会对它们进行递归降级。

单个插件模块的降级过程蕴含如下步骤：

  1. 如果存在，先运行插件模块的预迁徙步骤（参见第六章 治理模块数据理解更多信息）
  2. 从 Python 源码中加载模型定义并在必要时更新数据库构造（参见第四章 利用模型理解更多信息）
  3. 加载插件的数据文件并在必要时更新数据库内容（参见第六章 治理模块数据理解更多信息）
  4. 如果实例中启用了演示数据更新插件演示数据
  5. 如果模块有任何迁徙办法的话，运行插件模块的后置迁徙步骤（参见第六章 治理模块数据理解更多信息）
  6. 运行对插件视图定义的验证
  7. 如果启用了演示数据并启用了测试，运行该插件的测试（参见第十八章 自动化测试用例理解更多信息）
  8. 在数据库中更新模块状态
  9. 从插件的翻译文件中更新数据库中的翻译（参见第十一章 国际化理解更多信息）

📝留神更新未装置的插件模块时什么也不会做。然而装置已装置的插件模块会重新安装该插件，这会通过一些蕴含数据的数据文件产生一些预期外的问题，这些文件应由用户进行更新而非在惯例的模块降级解决时进行更新（参见第六章 治理模块数据中应用 noupdate 和 forcecreate 标记局部的内容）。通过用户界面不存在谬误的危险，但通过命令行时则有可能产生。

扩大常识 …

要当心依赖的解决。假设有一个实例你想要对其装置 sale、sale_stock 和 sale_specific 插件，sale_specific 依赖于 sale_stock，而 sale_stock 依赖于 sale。要装置这三者，你只须要装置 sale_specific，因为它会递归装置 sale_stock 和 sale 这两个依赖。要降级这三者，须要降级 sale，因为这样会递归降级其反向依赖，sale_stock 和 sale_specific。

治理依赖另一个比拟搞的中央是在你向曾经装置了一个版本的插件增加依赖的时候。咱们持续通过前例来了解这一问题。想像一下在 sale_specific 中增加了一个对 stock_dropshipping 的依赖。更新 sale_specific 插件不会主动装置新的依赖，也不会要求装置 sale_specific。在这种状况下，你会收到十分蹩脚的谬误音讯，因为插件的 Python 代码没有胜利加载，而插件的数据和模型表则已存在于数据库中。要解决这一问题，你须要进行该实例并手动装置新的依赖。

从 GitHub 装置插件模块

GitHub 是第三方插件一个很好的起源。很多 Odoo 合作伙伴应用 GitHub 来分享他们外部保护的插件，而 Odoo 社区联盟（OCA）在 GitHub 上独特保护着几百个插件。在你开始编写本人的插件之前，确保查看是否已有可间接应用的插件或者作为初始以持续扩大的插件。

这一部分向你展现如何从 GitHub 上克隆 OCA 的 partner-contact 我的项目并让其中所蕴含的插件模块在咱们实例中可用。

筹备工作

假如你心愿对客户(partner) 表单增加新的字段。默认 Odoo 客户模型不蕴含 gender 字段。如果要增加 gender 字段，须要新建一个模块。所幸邮件列表中有人通知你有 partner_contact_gender 这么一个插件模块，由 OCA 作为 partner-contact 我的项目的一部分进行保护。

本局部中所应用的门路反映了咱们在 标准化你的实例目录布局 一节中所举荐的布局。

如何装置 …

依照如下步骤来装置 partner_contact_gender：

  1. 进入我的项目目录：

    $ cd ~/odoo-dev/my-odoo/src

  2. 在 src/ 目录中克隆 partner-contact 我的项目的 14.0 分支：

    $ git clone --branch 14.0 \https://github.com/OCA/partner-contact.git src/partner-contact

  3. 批改插件门路来蕴含该目录并更新你的实例中的插件列表（参见本章中的

    配置插件门路

    和

    更新插件模块列表

    大节）。instance.cfg 中的 addons_path 一行应该是这样的：

    addons_path = ~/odoo-dev/my-odoo/src/odoo/odoo/addons, \~/odoo-dev/my-odoo/src/odoo/addons, \~/odoo-dev/my-odoo/src/, \~/odoo-dev/local-addons
  4. 装置 partner_contact_gender 插件（如果你不晓得如何装置该模块，参见后面的大节，装置并降级本地插件模块）

运行原理 …

Odoo 社区联盟的所有代码仓库都将他们本人的插件放在独自的子目录中，这与 Odoo 对插件门路中目录的要求是统一的。因而，只需复制某处的仓库并将其增加到插件门路中就够了。

扩大常识 …

有些维护者遵循不同的办法，每个插件模块一个仓库，放在仓库的根目录下。这种状况下，须要新建一个目录，在这个目录中增加插件门路并克隆所需维护者的插件到该目录中。记住在每次增加一个新仓库克隆时要更新插件模块列表。

对插件利用批改

GitHub 上可用的大部分插件须要进行批改并且不遵循 Odoo 对其稳固发行版所强制的规定。它们可能进行破绽修复或改善，蕴含你提交的问题或性能申请，这些批改可能会带来数据库模式的批改或数据文件和视图中的更新。这一部分解说如何装置降级后的版本。

筹备工作

假设你对 partner_contact_gender 报告了一个问题并收到告诉说该问题已在 partner-contact 我的项目 14.0 分支的最近一次订正中得以解决。这种状况下，你能够应用最新版本来更新实例。

如何批改 …

要对来自 GitHub 的插件进行源的变更，需执行如下步骤：

  1. 停止使用该插件的实例。
  2. 如果是生产实例请进行备份（参见第一章 装置 Odoo 开发环境中 治理 Odoo 服务端数据库 一节）。

  3. 进入克隆了 partner-contact 的目录：

    $ cd ~/odoo-dev/my-odoo/src/partner-contact

  4. 为该我的项目创立一个本地标签，这样万一呈现了解体还能够进行回退：

    $ git checkout 14.0$ git tag 14.0-before-update-$(date --iso)

  5. 获取源码的最新版本：

    $ git pull --ff-only
  6. 在数据库中更新 partner_contact_gender 插件（参见 装置并降级本地插件模块 一节）
  7. 重启实例

运行原理 …

通常，插件模块的开发者不时会公布插件的最新版本。这一更新个别蕴含破绽修复及新性能。这里，咱们将获取一个插件的新版本并在咱们的实例中更新它。

如果 git pull –ff-only 失败的话，能够应用如下命令回退到前一个版本：

$ git reset --hard 14.0-before-update-$(date --iso)

而后，能够尝试 git pull（不增加 –ff-only），它会产生一个合并，但这示意你对插件做了本地批改。

其它内容 …

如果更新这一步解体了，参见第一章 装置 Odoo 开发环境 从源码更新 Odoo一节获取复原的操作指南。记住要放弃首先在生产数据库的拷贝上进行测试。

利用及尝试倡议的拉取申请

在 GitHub 的世界中，拉取申请（PR）是由开发者所提交的申请，这样我的项目保护人员能够增加一些新的开发。比方一个 PR 可能蕴含破绽修复或新性能。这些申请在拉取到主分支之前会进行审核和测试。

这一部分解说如何对你的 Odoo 我的项目利用一个 PR 来测试破绽修复的改良。

筹备工作

在前一节中，假设你对 partner_contact_gender 报告了一个问题并收到一条告诉在拉取申请中问题已修复，尚未合并到我的项目的 14.0 分支中。开发人员要求你验证 PR #123 中的修复情况。你须要应用这一分支更新一个测试实例。

不应在生产数据库间接应用该分支，因而先创立一个带有生产数据库拷贝的测试环境（参见第一章 装置 Odoo 开发环境）。

如何操作 …

利用并测试一个插件的 GitHub 拉取申请，须要执行如下步骤：

  1. 进行实例

  2. 进入 partner-contact 所被克隆的目录：

    $ cd ~/odoo-dev/my-odoo/src/partner-contact

  3. 为该我的项目创立一个本地标签，这样万一呈现解体时你能够回退：

    $ git checkout 14.0
$ git tag 14.0-before-update-$(date --iso)

  4. 拉取 pull 申请的分支。这么做最容易的形式是应用 PR 编号，在开发者与你沟通时你应该能够看到。在本例中，这个拉取申请编号是 123：

    $ git pull origin pull/123/head
  5. 在你的数据库中更新 partner_contact_gender1 插件模块并重启该实例（如果你不晓得如何更新该模块的话请参见 装置并降级本地插件模块 一节）
  6. 测试该更新 – 尝试重现问题，或测试你想要的性能。

如果这不能运行，在 GitHub 的 PR 页面进行评论，阐明你做了什么以及什么不能运行，这样开发者能够更新这个拉取申请。

如果它没有问题，也在 PR 页面说下；这是 PR 验证流程中十分重要的一部分；这会减速主分支中的合并。

运行原理 …

咱们在应用一个 GitHub 性能，应用 pull/nnnn/head 分支名称来通过编号进行拉取申请的拉取，其中 nnnn 是 PR 的编号。Git pull 命令会合并近程分支到咱们的分支，在咱们根底代码中利用批改。在这之后，咱们更新插件模块、对其测试并向作者报告批改是胜利或是失败。

扩大常识 …

如果你想要同步测试它们，你能够针对雷同仓库的不同拉取申请重复本节中的第 4 步。如果你对后果很称心，能够创立一个分支来保留对利用了扭转的后果的援用：

$ git checkout -b 14.0-custom

应用一个不同的分支会有助于记住你没有应用 GitHub 的版本，而是一个自定义的版本。

📝git branch 命令可用于列出你仓库中的所有本地分支。

从这开始，如果须要利用来自 GitHub 中 14.0 分支的最近一个审核版本，须要在拉取时不应用 –ff-only：

$ git pull origin 14.0
退出移动版