我们如何管理拉取请求

---

本文记录了我们如何在 PowerShell-Docs 存储库中管理拉取请求。本文旨在为 PowerShell-Docs 团队成员提供工作帮助。它在此发布是为了为我们的公共贡献者提供流程透明度。

最佳实践

• 提交 PR 的人不应在未经同行评审的情况下合并 PR。
• 提交 PR 时指定同行评审员。尽早分配可以让审稿人更快地回复编辑评论。
• 使用注释来描述所提交变更的性质。请务必@提及审阅者。例如，如果更改很小并且您不需要完整的技术审查，请在评论中对此进行解释。
• 审稿人应在适当的时候使用评论建议功能，以使作者更容易接受建议的更改。有关更多信息，请参阅审查拉取请求中建议的更改。

公关流程步骤

1. 作者：创建公关

   • 填写公关模板
2. 链接 PR 解决的任何问题
3. 使用 GitHub 的自动关闭功能来关闭问题
4. 完成并核对清单中的每一项
5. 作者：指定同行评审员
6. 审稿人：校对和评论（必要时）
7. 作者：纳入评论反馈
8. 两者：查看预览渲染
9. 两者：查看验证报告 - 修复警告和错误
10. 审阅者：将审阅标记为“已批准”
11. 回购管理员：合并 PR（标准见下文）

内容审阅者清单

请参阅编辑清单以获取更全面的列表。

• 校对语法、风格、简洁性、技术准确性
• 确保示例仍然适用于目标版本
• 检查预览渲染
• 检查元数据 - ms.date，删除 ms.assetid，确保必填字段

• 验证降价正确性

  • 有关特定于内容的格式规则，请参阅样式指南

重新组织示例如下：

• 介绍句

代码和输出

代码详细解释（根据需要）

检查超链接的准确性

• 替换或删除 TechNet/MSDN 链接

确保重定向到目标的最少数量

确保 HTTPS

正确的链接类型

• 本地文件的文件链接

文档集外部文件的 URL 链接

从 URL 中删除区域设置

简化指向 learn.microsoft.com 的 URL

验证版本化内容在所有版本中均正确

• 查看版本化内容更改报告以查看汇总的更改

分支合并过程

main 分支是唯一合并到 live 的分支。来自短期（工作）分支的合并应该被压缩。

Merge from/to release-branch main live working-branch squash and merge squash and merge Not allowed release-branch — merge Not allowed main rebase — merge

公关合并清单

• 内容审核完成
• 更改的正确目标分支
• 没有合并冲突

• 所有验证和构建步骤均通过

  • 应修复警告和建议（有关例外情况，请参阅注释）
• 没有损坏的链接
• 检查清单操作已运行并通过
• 如果触发了授权检查，则通过

根据表合并

笔记

可以忽略以下警告：

Can't find service name for `<version>/<modulepath>/About/About.md`

Metadata with following name(s) are not allowed to be set in Yaml header, or as file level
metadata in docfx.json, or as global metadata in docfx.json: `locale`. They are generated by
Docs platform, so the values set in these 3 places will be ignored. Please remove them from all
3 places to resolve the warning.

合并 PR 时，目标分支的 HEAD 会发生更改。任何基于以前的 HEAD 的开放 PR 现在都已经过时了。可以使用管理员权限合并过时的 PR，以覆盖 GitHub 中的合并警告。如果之前合并的 PR 没有触及相同的文件，那么这样做是安全的。单击更新分支按钮是最安全的选择。选择使用变基更新选项。有关更多信息，请参阅更新您的拉取请求分支。

发布到直播

需要定期将 main 分支中累积的更改发布到实时网站。

• main 分支会在每个工作日下午 3 点（太平洋标准时间）合并到 live。

• 任何重大更改后，应将 main 分支合并到 live 中。

  • 更改 50 个或更多文件
• 合并发布分支后
• 对存储库或文档集配置的更改（docfx.json、OPS 配置、构建脚本等）
• 重定向文件的更改
• 目录的变更
• 合并“项目”分支后（内容重组、批量更新等）