跳至主要内容

管理 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 自己添加变更日志。完成后，删除“缺少变更日志”标签。
  • 缺少测试计划的 PR - 打开 Pull Request 并查找测试计划。如果测试计划看起来足够，请删除“缺少测试计划”标签。如果没有测试计划，或者看起来不完整，请添加一条评论，礼貌地要求作者考虑添加测试计划。

Pull Request 必须通过所有测试才能合并。它们在 main 和 Pull Request 上的每次提交时都会运行。帮助我们快速准备好 Pull Request 以供审查的一种方法是 搜索提交前测试失败的 Pull Request 并确定它们是否需要修改。失败的测试通常列在主题的底部附近，在“某些检查未成功”下。

  • 快速浏览一下 main 上最新的测试运行。main 是否为绿色？如果是，
    • 错误看起来是否与此 Pull Request 中的更改有关？请作者调查。
    • 即使 main 目前为绿色，也要考虑 Pull Request 中的提交可能基于 main 出现故障时的某个时间点的提交的可能性。如果您认为可能是这种情况，请作者将其更改重新设置为 main 之上，以便引入他们在开始处理 Pull Request 后可能已着陆的任何修复程序。
  • 如果 main 似乎已损坏，请查找任何 标记为“CI 测试失败”的问题。
    • 如果您发现一个似乎与 main 上的故障相关的问题，请返回到 Pull Request 并感谢作者提出这些更改，并让他们知道测试故障可能与他们的特定更改无关（不要忘记链接回 CI 测试失败问题，因为这将有助于作者了解他们何时可以再次尝试运行测试）。
    • 如果您找不到描述您在 main 上观察到的问题的现有 CI 测试失败问题，请提交一个新问题并使用“CI 测试失败”标签让其他人知道 main 已损坏（请参阅 此问题 以了解示例）。

我们如何优先处理 PR​

Meta 的 React Native 团队成员力求快速审查 Pull Request，大多数 PR 都将在一个星期内得到回复。

PR 如何合并？​

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

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

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

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

机器人​

在您审查和处理 Pull Request 时，您可能会遇到一些 GitHub 机器人帐户留下的评论。这些机器人已设置用于辅助 Pull Request 审查过程。请参阅 机器人参考 以了解更多信息。

Pull Request 标签​

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