合并拉取请求

本指南面向维护人员。这些特殊人员具有对一个或多个 Jekyll 存储库的写入访问权限,并帮助合并他人的贡献。您可能会觉得这里的内容很有趣,但它绝对不是面向所有人的。

代码审查

所有拉取请求都应接受代码审查。代码审查是优秀工程团队的基本价值。除了验证正确性之外,它还促进了社区意识,并让其他维护人员了解代码库的所有部分。简而言之,代码审查对于健康的开源项目至关重要。

在合并之前,请阅读我们的 审查拉取请求 指南。值得注意的是,如果针对代码,则更改必须经过测试,并且至少有两名维护人员必须给予 OK。

合并

我们有一个有用的机器人,我们用它来合并拉取请求。我们不使用 GitHub.com 界面,原因有两个

  1. 您无法在移动设备上修改任何内容(例如标题、标签)
  2. 我们希望在每个版本的 History.markdown 文件中提供一致的纸质记录

要合并拉取请求,请留下评论感谢贡献者,然后添加特殊合并请求

Thank you very much for your contribution. Folks like you make this project and community strong. :heart:

@jekyllbot: merge +dev

合并请求由三部分组成

  1. @jekyllbot: – 这是我们的机器人处理命令时查找的前缀
  2. merge – 命令
  3. +dev – 更改所属的类别。

类别与 History.markdown 文件中的标题相匹配,它们是

  1. 重大增强 (+major) – 重大更新或代码中的重大更改,需要进行重大版本升级 (v3 ~> v4)
  2. 次要增强 (+minor) – 次要更新(带有标签 featureenhancement),需要进行次要版本升级 (v3.1 ~> v3.2)
  3. 错误修复 (+bug) – 对代码的更正,不会更改或添加功能,需要进行修补程序版本升级 (v3.1.0 ~> v3.1.1)
  4. 文档 (+doc) - 对 docs/_docs/ 中文档的更改
  5. 网站增强 (+site) – 对 docs/https://jekyll.ruby-lang.org.cn 源的更改
  6. 开发修复 (+dev) – 不影响面向用户的功能或文档的更改,例如测试修复或内部依赖项升级
  7. 前向移植 (+port) — 应用于以前版本的 Jekyll 的错误修复,已拉取到 master 中,例如从 3-1-stablemaster 的精选提交

一旦 @jekyllbot 合并了拉取请求,你应该会看到三件事

  1. 成功合并
  2. 如果尚未应用,则添加必要的类别标签
  3. History.markdown 文件的提交,其中添加了有关更改的说明

如果你忘记了类别,没关系。你始终可以返回并稍后将该行移动到正确的类别标题。对于 jekyll/jekyll,类别始终是必需的,但许多插件的更改太少,无需变更日志类别。

欢呼

你做到了!感谢成为我们官方 Jekyll 项目之一的维护者。你的工作对每天依赖 Jekyll 的数千名用户来说意义重大。 :heart: