拉取请求过程

提交拉取请求 (PR) 后，该 PR 将经历一系列检查和审查，以确保建议的更改可进行合并。有关 PR 的更多背景信息，请参阅 Git 和 GitHub 基础知识。

验证

PR 可能需要经历一个或多个 PR 验证和批准流程，才能合并到其目标分支中。选择创建拉取请求后，GitHub 会运行为存储库配置的验证。验证过程完成后，PR 中会显示结果。

验证过程因提议的更改范围和目标存储库的规则而异。提交 PR 后，预期会发生以下一项或多项操作：

可合并性：首先进行基线 GitHub 可合并性测试，以验证分支中提议的更改是否与目标分支冲突。如果 PR 表明未通过该测试，须调解导致合并冲突的内容，然后再继续进行处理。
贡献许可协议 (CLA)：作为非 Microsoft 参与者，如果你正在参与公共存储库，则在首次向该存储库提交 PR 时可能会要求你完成简短的 CLA。完成 CLA 步骤后，你的 PR 会得到处理。
标签：将自动向你的 PR 应用标签，以指示 PR 在整个验证工作流期间的状态。例如，新的 PR 可能会自动收到“do-not-merge”标签，指示 PR 尚未完成验证、评审和签名步骤。
验证和生成：自动化检查会验证更改是否已通过验证测试。验证测试可能会生成警告或错误，要求你对 PR 中的一个或多个文件进行编辑，然后才能将其合并。验证测试结果将作为注释添加到 PR 中以供查看，可能通过电子邮件发送给你。
过渡：验证和生成成功后，受更改影响的文章页面会自动部署到过渡环境以供审阅。 PR 备注中包含预览 URL。
自动合并：如果 PR 通过了验证测试并符合特定条件，则可能会自动合并该 PR。在这种情况下，你无需执行任何其他操作。

完成所有 PR 处理后，应查看结果（例如，PR 注释、生成结果）。在签核合并之前，确定是否需要进行更多更改。出于以下任意原因，可能需要更改内容：

如需进行更改，可直接在 PR 中编辑内容，也可返回到 VS Code 进行更改。完成后，将更改提交到工作分支。 PR 会与更改一同自动更新。

每次向同一工作分支添加提交时，均会自动将该提交添加到 PR。每次提交后，发布系统均会自动重新运行验证与审查流程。

如果已处理所有反馈和验证错误，且已准备好合并更改，则可通过创建用于读取 #sign-off 的新注释对 PR 进行签核。必须输入 #sign-off 注释才能合并更改。即使所有审查与验证检查均已通过，你也有责任使用此注释来告知 PR 审查者和存储库管理员已可合并这些更改。

审查者确定 PR 没有问题且已签核后，便会将更改合并到默认分支中并关闭 PR。

注释自动化通过向 PR 分配相应的标签，以便对存储库没有写入权限的用户能完成写入级别的操作。如果在已实现注释自动化的存储库中操作，请使用下表中列出的“井号标签”来分配标签、更改标签或关闭 PR。每当有人对其文章提议更改时，Microsoft 作者也会收到电子邮件通知，以便进行审查和签核。

井号标签注释	作用
`#sign-off`	自动分配“ready-to-merge”标签，让存储库中的审阅者知道 PR 已做好评审/合并准备。如果你不是被列出的作者，但想尝试使用 `#sign-off` 注释对一个公共存储库 PR 进行签名，该 PR 会更新以指示只有被列出的作者可以分配标签。
`#hold-off`	在你改变主意或出错的情况下，移除“ready-to-merge”标签。在专用存储库中，此操作将分配“请勿合并”标签。
`#please-close`	当你决定不合并更改时，关闭 PR。
`#please-open`	重新打开关闭的 PR 或问题。

PR 必须由 PR 审查者进行合并，然后更改才能包括在下个计划发布运行中。通常情况下，将按提交顺序审阅和合并各个 PR。

供稿内容在得到批准并进行合并后，发布过程会选取这些内容。发布时间可能会有所不同，但通常每个工作日至少会发布一次，具体取决于负责管理你参与贡献的存储库的团队。文章发布后出现在网上最多耗时 45 分钟。

你的更改发布后，它们会立即在 Microsoft Learn 上线以供其他人学习！

就这么简单！你已完成参与 Microsoft Learn 内容编辑！