管理拉取请求

¥Managing pull requests

你应该：

¥You should:

• 使用 GitHub 点评

  ¥use GitHub reviews

• 针对 开发者指南标准 的审查

  ¥review against the Developer guide criteria

• 通过 rebasing 解决冲突

  ¥resolve conflicts by rebasing

• 分配零个或多个 pr: * 标签

  ¥assign zero or more pr: * labels

你不应该使用任何：

¥You should not use any:

• 其他标签

  ¥other labels

• milestones

合并

¥Merging

合并 PR 时，你应该：

¥When merging a PR, you should:

1. 根据你的判断来确定所需的批准数量：

   ¥Use your judgment for the number of approvals needed:

   • 对于简单的修复来说，一次批准通常就可以了

     ¥one approval is usually fine for simple fixes

   • 两次批准通常对于更大的更改很有用

     ¥two approvals are often useful for bigger changes

2. 如果适用，请使用 GitHub 界面添加 changeset：

   ¥If applicable, add a changeset using the GitHub interface:

   • 在条目前面加上以下任一前缀："已删除"、"改变了"、"已弃用"、"添加"、"固定的" 或 "安全"

     ¥prefix the entry with either: "Removed", "Changed", "Deprecated", "Added", "Fixed" or "Security"

   • 如果适用，请以规则名称开头，例如 “固定的：自定义属性出现 unit-disallowed-list 次误报”。

     ¥if applicable, lead with the name of the rule, e.g. "Fixed: unit-disallowed-list false positives for custom properties".

3. "挤压并合并" 提交确保生成提交消息：

   ¥"Squash and merge" commits ensuring the resulting commit message:

   • 要么匹配变更集条目，但使用现在时，例如 “修复自定义属性的 unit-disallowed-list 个误报”

     ¥either matches the changeset entry but in the present tense, e.g. "Fix unit-disallowed-list false positives for custom properties"

   • or 是句子大小写且具有描述性，例如 “重构 colour-no-named 以使用新的 AST”

     ¥or is in sentence case and descriptive, e.g. "Refactor colour-no-named to use new AST"