跳到主要内容

管理拉取请求

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

Pull Request 应包含三个主要部分

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

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

审查 PR​

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

所以你找到了一个你自信能审查的 Pull Request。请使用 GitHub 审查功能，并清晰、礼貌地沟通任何建议的更改。

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

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

Pull Request 在合并之前必须通过所有测试。它们在每次提交到 main 和 Pull Request 时运行。帮助我们准备好 Pull Request 以供审查的快速方法是搜索未通过预提交测试的 Pull Request 并确定是否需要修订。失败的测试通常列在线程底部，“Some checks were not successful”下方。

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

我们如何优先处理 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”（合并到 fbsource），这意味着它将被导入，并且生成的 diff 将自动获得批准，除非有任何失败，更改最终将同步回 main。Pull Request 也可以“imported to Phabricator”（导入到 Phabricator），这意味着更改将被复制到内部 diff，这将需要进一步的审查和批准才能合并。

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

机器人​

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

Pull Request 标签​

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