合并 Pull Request

本指南面向维护者。 这些特别的人拥有一个或多个 Jekyll 仓库的 写入权限（write access），并负责帮助合并其他人的贡献。你可能会觉得这里的内容很有趣，但它显然并不适合所有人。

代码审核

所有 Pull Request 都必须经过代码审核（Code Review）。

代码审核是优秀工程团队中的一种核心价值观。

除了验证代码正确性之外，它还能够：

简而言之，代码审核对于一个健康的开源项目至关重要。

在合并之前，请务必先阅读我们的 Pull Request 审核指南。

特别需要注意：

合并

我们使用了一个小巧实用的机器人来帮助合并 Pull Request。

我们不直接使用 GitHub.com 的网页界面进行合并，原因有两个：

  1. GitHub 移动端无法修改很多内容（例如标题、标签等）
  2. 我们希望在 History.markdown 中为每次发布保留统一规范的变更记录

要合并一个 Pull Request，请先留言感谢贡献者，然后添加特殊的合并命令：

```text id=”9gy54v” Thank you very much for your contribution. Folks like you make this project and community strong. ❤️

@jekyllbot: merge +dev ```

该合并命令由三部分组成：

  1. @jekyllbot: —— 机器人识别命令的前缀
  2. merge —— 执行的命令
  3. +dev —— 当前修改所属的分类

这些分类对应 History.markdown 文件中的各个标题，具体如下：

  1. Major Enhancements (+major) 大型功能更新或破坏性修改，需要升级主版本号（例如 v3 → v4）

  2. Minor Enhancements (+minor) 小型功能更新（通常带有 feature 或 enhancement 标签），需要升级次版本号（例如 v3.1 → v3.2）

  3. Bug Fixes (+bug) Bug 修复，不增加或修改功能，需要升级补丁版本号（例如 v3.1.0 → v3.1.1）

  4. Documentation (+doc) 修改 docs/_docs/ 中的文档内容

  5. Site Enhancements (+site) 修改 https://jekyllrb.com 网站源码（位于 docs/）

  6. Development Fixes (+dev) 不影响用户功能或文档的修改，例如测试修复、内部依赖升级等

  7. Forward Ports (+port) 从旧版本分支同步到 master 的 Bug 修复，例如从 3-1-stable cherry-pick 到 master 的提交

当 @jekyllbot 成功合并 Pull Request 后，你应该会看到以下三件事：

  1. Pull Request 已成功合并
  2. 自动添加对应分类标签（如果之前尚未添加）
  3. 自动向 History.markdown 添加一条变更记录

如果你忘记填写分类，也没关系。

之后仍然可以手动将对应记录移动到正确的分类标题下。

对于 jekyll/jekyll 主仓库来说，分类始终是必须的。

但很多插件项目的变更较少，不一定需要 changelog 分类。

庆祝一下

你成功了！

感谢你成为 Jekyll 官方项目的维护者。

你的工作对于每天依赖 Jekyll 的数千名用户来说意义重大。❤️