管理拉取请求
本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →
评审拉取请求可能需要大量时间。在某些情况下，评审所需的时间甚至可能超过编写和提交变更的时间！因此，有必要进行一些初步工作，确保每个拉取请求都处于良好的可评审状态。
一个合格的拉取请求应包含三个主要部分：
-
摘要：帮助我们理解变更背后的动机
-
变更日志：帮助我们编写发布说明，同时作为变更的简要总结
-
测试计划：这可能是拉取请求中最重要的部分。测试计划应是可复现的逐步指南，让评审者能验证变更是否按预期工作。对于用户可见的变更，建议附上截图或视频
任何拉取请求都可能涉及您不熟悉的 React Native 领域。即使您认为自己不适合评审某个拉取请求，仍可通过添加标签或向作者询问更多信息来提供帮助
评审拉取请求
拉取请求必须通过 GitHub 的评审功能获得批准后才能合并。虽然任何人都可以评审和批准拉取请求，但我们通常只接受来自核心贡献者的批准
当您发现一个有信心评审的拉取请求时，请使用 GitHub 评审功能，清晰礼貌地提出修改建议
建议从标记为缺少变更日志或测试计划的拉取请求开始：
-
缺少变更日志的 PR - 尝试通过编辑 PR 添加变更日志，完成后移除"Missing Changelog"标签
-
缺少测试计划的 PR - 检查测试计划是否充分，若充分则移除"Missing Test Plan"标签；若缺失或不完整，请礼貌地请求作者补充
拉取请求必须通过所有测试才能合并。这些测试会在每次提交到 main 分支或拉取请求时运行。快速帮助 PR 进入评审状态的方法是搜索未通过预提交测试的 PR，通常在讨论区底部的"Some checks were not successful"处查看失败详情
-
快速查看main 分支的最新测试结果：
- 若
main状态为绿色：- 检查失败是否与该 PR 的变更相关？请作者排查
- 即使当前
main正常，但 PR 可能基于某个main损坏时的提交。若存在此情况，请作者将变更变基(rebase)到最新的main以获取修复
- 若
-
如果
main分支似乎存在问题，请查找标记为 "CI Test Failure" 的问题。- 如果发现与
main分支失败相关的问题，请回到该 Pull Request 中感谢贡献者提交这些变更，并告知他们测试失败可能与其特定修改无关（务必附上 CI Test Failure 问题的链接，这有助于贡献者了解何时可以重新运行测试）。 - 如果找不到描述
main分支问题的现有 CI Test Failure 问题，请提交新问题并使用 "CI Test Failure" 标签告知其他人main分支存在问题（示例请参考此 issue）。
- 如果发现与
PR 优先级处理原则
Meta 的 React Native 团队成员致力于快速审查 Pull Request，大多数 PR 会在一周内获得回复。
PR 如何被合并？
React Native 的 GitHub 仓库实际上是 Meta 单体仓库中子目录的镜像。因此 Pull Request 并非以传统方式合并，而是需要作为"差异文件"导入 Meta 的代码审查系统。
导入后，变更将通过一系列测试。其中部分测试属于合并阻塞项（land-blocking），意味着必须通过这些测试才能合并变更。Meta 始终使用 main 分支的 React Native，某些变更可能需要 Facebook 员工为您的 PR 附加内部变更才能合并。例如，如果您重命名模块名称，则必须同步更新 Facebook 内部所有调用点才能合并变更。若差异文件成功合并，变更最终将通过 ShipIt 以单次提交形式同步回 GitHub。
Meta 员工使用定制的 GitHub 浏览器扩展导入 PR，有两种方式："落地到 fbsource"（自动导入并批准差异文件，若无失败则变更最终同步至 main）或"导入到 Phabricator"（将变更复制到内部差异文件，需进一步审查批准后才能合并）。
机器人
在审查和处理 PR 时，您可能会遇到 GitHub 机器人账号的评论。这些机器人用于辅助 PR 审查流程，详情请参阅机器人参考文档。
PR 标签说明
-
Merged：标记已关闭的 PR，表示其变更已合并到核心仓库。由于 PR 并非直接在 GitHub 合并（而是将变更作为补丁导入并排队审查），批准后变更在 Meta 单体仓库的应用结果会作为新提交同步到 GitHub，因此需要此标签说明实际状态。 -
Blocked on FB：PR 已导入但变更尚未应用。