跳到主要内容

管理拉取请求

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

一个拉取请求应该包含三个主要部分

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

任何拉取请求可能都需要对您不熟悉的 React Native 某些领域有更深入的了解。即使您觉得您不是审查拉取请求的合适人选，您仍然可以通过添加标签或向作者索取更多信息来提供帮助。

审查 PRs​

拉取请求需要使用 GitHub 的审查功能进行审查和批准才能合并。虽然任何人都可以审查和批准拉取请求，但我们通常只在批准来自其中一位贡献者时才认为拉取请求已准备好合并。

所以您已经找到了一个您有信心审查的拉取请求。请使用 GitHub 审查功能，并清晰礼貌地传达任何建议的更改。

考虑从那些被标记为缺少更新日志或测试计划的拉取请求开始。

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

拉取请求必须通过所有测试才能合并。它们在main上的每次提交和拉取请求上运行。帮助我们为审查准备拉取请求的一个快速方法是搜索未通过预提交测试的拉取请求，并确定它们是否需要修改。失败的测试通常列在线程底部，在“某些检查未成功”下方。

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

我们如何优先处理 PRs​

Meta 的 React Native 团队成员旨在快速审查拉取请求，大多数 PRs 将在一周内获得回复。

PR 如何合并？​

React Native GitHub 存储库实际上是 Meta 的一个 monorepo 中一个子目录的镜像。因此，拉取请求不是以传统意义上合并的。相反，它们需要作为“diff”导入到 Meta 的内部代码审查系统中。

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

Meta 员工正在使用一个自定义的 GitHub 浏览器扩展，它可以通过两种方式导入拉取请求：拉取请求可以“提交到 fbsource”，这意味着它将被导入，并且生成的 diff 将自动批准，如果没有失败，更改最终将同步回main。拉取请求也可以“导入到 Phabricator”，这意味着更改将被复制到内部 diff，这将需要进一步的审查和批准才能提交。

自定义浏览器扩展的截图。“Import to fbsource”按钮用于在内部导入拉取请求。

机器人​

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

拉取请求标签​

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