拉取请求的合并工作流

审查阶段

• 是否准守要求的代码风格？否则合并后再进行修改的话，费时费力。
• 是否在技术可行性方面可以做得更好？
• 是否修改了不应该动的地方？是否自行进行了全文格式化？是否提交了编译文件？
• 是否对改动的 API 撰写了合适的文档注释？

合并阶段

通过审查的拉取请求，可以被 任意 核心开发者合并。由核心开发者提交的拉取请求，应当由本人合并。

• 合并执行：

  • GitHub 提供多种合并方案，我们会在以下两种方案中选择：
    • Merge 合并。拉取请求的提交具有良好的原子性，清晰明朗的提交记录、详细得当的变更记录时，选择此方案。
    • Squash 整合。拉取请求存在大量零散的提交记录时选择此方案。提交时需撰写 良好的提交记录。

• 合并完成：

  • 将拉取请求本身，或相关 议题 纳入合适的里程碑。扩展程序的拉取请求不得纳入核心里程碑，由当前版本项目委员会处理。
  • 根据实际情况结束相关议题。
  • 执行后续任务：
    • 合并与此议题相关的语言文件、扩展程序及文档拉取请求。
    • 更新文档站点。
  • 如有需要，为后续任务创建议题。