跳到主要内容

管理 Pull Request

评审 Pull Request 可能需要相当长的时间。在某些情况下，评审所需的时间可能比编写和提交更改所需的时间还要长！因此，有必要做一些前期工作，以确保每个 Pull Request 都处于适合评审的良好状态。

一个 Pull Request 应包含三个主要部分

  • 概要。这有助于我们理解更改背后的动机。
  • 更新日志。这有助于我们编写发布说明。它也作为你更改的简要总结。
  • 测试计划。这可能是 Pull Request 中最重要的部分。测试计划应提供可复现的步骤指南，以便评审者验证你的更改是否按预期工作。对于用户可见的更改，附加截图或视频也是个好主意。

任何 Pull Request 都可能需要对 React Native 的某个领域有更深入的了解，而你可能不熟悉这个领域。即使你觉得自己不是评审 Pull Request 的合适人选，你仍然可以通过添加标签或向作者询问更多信息来提供帮助。

评审 PR​

Pull Request 需要使用 GitHub 的评审功能进行评审和批准后才能合并。虽然任何人都可以评审和批准 Pull Request，但我们通常只在获得 贡献者 的批准时，才认为 Pull Request 已准备好合并。

如果你找到一个你有信心评审的 Pull Request。请利用 GitHub 的评审功能，并清晰礼貌地沟通任何建议的更改。

可以考虑从那些被标记为缺少更新日志或测试计划的 Pull Request 开始。

  • 看起来缺少更新日志的 PR - 看一下，看看你是否可以通过编辑 PR 自己添加更新日志。添加后，移除“Missing Changelog”（缺少更新日志）标签。
  • 缺少测试计划的 PR - 打开 Pull Request 查看是否有测试计划。如果测试计划看起来足够，移除“Missing Test Plan”（缺少测试计划）标签。如果没有测试计划或看起来不完整，礼貌地添加评论，请作者考虑添加测试计划。

Pull Request 必须通过所有测试才能合并。测试会在 main 分支的每次提交和每个 Pull Request 上运行。一个帮助我们快速准备 Pull Request 以供评审的方法是 搜索那些未能通过预提交测试的 Pull Request，并确定它们是否需要修改。失败的测试通常列在讨论串的底部，“Some checks were not successful.”（部分检查未成功）下方。

  • 快速浏览一下 main 分支上的最新测试运行结果。main 分支是绿色的吗？如果是，
    • 失败看起来与此 Pull Request 中的更改有关吗？请作者调查。
    • 即使 main 分支当前是绿色的，也要考虑 Pull Request 中的提交可能基于 main 分支曾经处于损坏状态时的提交。如果你认为可能是这种情况，请作者将他们的更改 rebase 到 main 分支之上，以便拉取他们开始处理 Pull Request 后可能已合入的任何修复。
  • 如果 main 分支似乎损坏了，查找任何标记为“CI Test Failure”的 issue。
    • 如果你找到一个与 main 分支上的失败相关的 issue，回到 Pull Request 并感谢作者提出了这些更改，并告知他们测试失败可能与他们的特定更改无关（不要忘记链接回“CI Test Failure”issue，因为这将帮助作者知道何时可以再次尝试运行测试）。
    • 如果你找不到描述你在 main 分支上观察到的问题的现有“CI Test Failure”issue，请提交一个新的 issue 并使用“CI Test Failure”标签，以告知其他人 main 分支已损坏（请参阅此 issue 作为示例）。

我们如何确定 PR 的优先级​

Meta 的 React Native 团队成员致力于快速评审 Pull Request，大多数 PR 会在一周内得到回复。

PR 如何合并？​

React Native 的 GitHub 仓库实际上是 Meta 单体仓库中一个子目录的镜像。因此，Pull Request 并不会以传统方式合并。相反，它们需要作为 “diff” 导入到 Meta 的内部代码评审系统。

导入后，这些更改将经过一系列测试。其中一些测试是阻碍合入的（land-blocking），这意味着它们必须成功才能合并 diff 的内容。Meta 始终从 main 分支运行 React Native，并且某些更改可能需要 Facebook 员工将内部更改附加到你的 Pull Request 中才能合并。例如，如果你重命名一个模块名称，所有 Facebook 内部调用点都必须在同一个更改中更新才能合并。如果 diff 成功合入，更改最终将由 ShipIt 同步回 GitHub，作为一个单独的提交。

Meta 员工正在使用一个自定义的 GitHub 浏览器扩展，该扩展可以通过两种方式之一导入 Pull Request：Pull Request 可以“合入 fbsource”（landed to fbsource），这意味着它将被导入，结果的 diff 将自动获得批准，如果没有失败，更改最终将同步回 main 分支。Pull Request 也可以“导入到 Phabricator”（imported to Phabricator），这意味着更改将被复制到内部 diff，该 diff 在合入之前需要进一步的评审和批准。

自定义浏览器扩展的截图。“Import to fbsource”按钮用于内部导入 Pull Request。

机器人​

在评审和处理 Pull Request 时，你可能会遇到一些 GitHub 机器人账号留下的评论。这些机器人是为了协助 Pull Request 评审过程而设置的。请参阅机器人参考以了解更多信息。

Pull Request 标签​

  • Merged（已合并）：应用于已关闭的 PR，表示其更改已并入核心仓库。这个标签是必要的，因为 Pull Request 不是直接在 GitHub 上合并的。相反，包含 PR 更改的补丁会被导入并排队等待代码评审。一旦获批，将这些更改应用到 Meta 内部单体仓库上的结果会同步到 GitHub，作为一个新的提交。GitHub 不会将该提交归因于原始 PR，因此需要一个标签来传达 PR 的真实状态。
  • Blocked on FB（被 FB 阻塞）：PR 已导入，但更改尚未应用。