管理拉取请求

2025-04-03

本文介绍了如何在 PowerShell-Docs 存储库中管理拉取请求。本文旨在成为 PowerShell-Docs 团队成员的工作辅助材料。我们在此处发布此信息，为公共参与者提供流程透明度。

最佳做法

请求评审。未经同级评审，提交 PR 的人不应合并 PR。
提交 PR 时指定同级评审员。尽早指派任务可以让审阅者更快地做出评论性反馈。
使用注释描述正在提交的更改的性质。例如，如果更改很小，请解释更改，并且不需要完整的技术评审。请务必 @mention 评审员。
使用批注建议功能使作者更容易接受建议的更改。有关详细信息，请参阅审查拉取请求中的建议更改。

PR 流程步骤

编写器：创建 PR
- 填写 PR 模板
- 链接 PR 解决的任何问题
- 使用 GitHub 的自动关闭功能关闭问题
- 检查并核对清单上的每一项
编写器：分配同级评审员
审阅者：校对和批注（如有必要）
编写器：采纳评审反馈
两者：查看预览呈现
两者：查看验证报告 - 修复警告和错误
审阅者：标记审阅“已批准”
存储库维护者：合并 PR

内容审阅者清单

如需更全面的列表，请参阅编辑清单。

审校语法、风格、简洁性、技术准确性
确保示例仍适用于目标版本
检查预览呈现
检查元数据 - ms.date，删除 ms.assetid，确保必填字段
验证 markdown 正确性
- 请参阅内容特定的格式规则样式指南
按如下所示重新组织示例：
- 简介段落
- 代码和输出
- 代码的详细说明（如有必要）
检查超链接的准确性
- 替换或删除 TechNet/MSDN 链接
- 确保重定向到目标的次数最少
- 确保 HTTPS
- 正确的链接类型
  - 本地文件的文件链接
  - 文档集外部文件的 URL 链接
- 从 URL 中删除区域设置
- 简化指向 learn.microsoft.com 的 URL
验证版本化的内容在所有版本中是否正确
- 查看版本控制内容更改报告

分支合并过程

main 分支是唯一应合并到 live的分支。应在合并到 main 之前，应先压缩来自生存期较短（工作）分支的合并。

合并从/到	发布分支	主	实时
工作分支	压缩并合并	压缩并合并	不允许
发布分支	—	合并	不允许
主	变基	—	合并

PR 合并核对清单

内容评审完成
确定更改的正确目标分支
无合并冲突
所有验证和生成步骤都已通过
- 警告和建议应予以纠正（请参阅注释以了解例外情况）
- 没有断开的链接
- 核对清单操作已运行并通过
- 如果触发了授权检查，则说明已成功通过。
根据表合并

注释

可以忽略以下警告：

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 现在都已经过时了。维护者有权覆盖合并警告，并在 GitHub 中合并过时的 PR。如果以前合并的 PR 没有触及相同的文件，那么合并过时的 PR 是安全的。

若要更新 PR，请选择 更新分支 按钮。选择使用变基更新选项。有关详细信息，请参阅更新拉取请求分支。

发布到上线版本

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

太平洋标准时间每个工作日下午 3 点，main 分支合并为 live。
在发生任何重大更改后，应将 main 分支合并到 live。
- 对 50 个或多个文件的更改
- 合并发布分支后
- 存储库或文档集配置的更改（docfx.json、OPS 配置、生成脚本等）
- 重定向文件的更改
- TOC 的更改
- 合并“项目”分支（内容重新组织、批量更新等）后

通过