跳到主要内容

管理 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 以供审查的一种快速方法是搜索未通过 pre-commit 测试的 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 的 monorepo 之一的子目录的镜像。因此，Pull Request 不是以传统意义上的方式合并的。相反，它们需要作为 “diff” 导入到 Meta 的内部代码审查系统中。

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

Meta 员工正在使用 GitHub 的自定义浏览器扩展程序，该扩展程序可以通过两种方式导入 Pull Request：可以将 Pull Request “landed to fbsource”，这意味着它将被导入，并且生成的 diff 将自动批准，并且在没有任何失败的情况下，更改最终将同步回 main 分支。Pull Request 也可以“imported to Phabricator”，这意味着更改将被复制到内部 diff，这将需要进一步的审查和批准才能落地。

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

Bot​

当你审查和处理 Pull Request 时，你可能会遇到一些 GitHub bot 帐户留下的评论。这些 bot 已被设置为协助 Pull Request 审查过程。请参阅Bot 参考以了解更多信息。

Pull Request 标签​

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