提交消息#

提交消息为差异本身无法传达的更改提供上下文。它们有助于其他人理解更改，并在数月或数年后回顾更改时记录更改背后的原因。

本页提供适用于大多数 GNOME 模块的通用建议和指南。某些模块具有不同的或额外的约定，因此建议在贡献之前检查特定于项目的文档并查看现有的提交消息。

包含推理的 GNOME 提交风格的更详细文档可在 coala 项目 处获得。

结构#

提交消息使用以下结构

  1. 简要描述，总结提交内容

  2. 主要描述（正文）

  3. 指向相关问题的链接或引用（可选）

不同的部分由空行（两个换行符）分隔。

诸如 Commit 应用 之类的专用工具可以帮助进行格式化。

示例#

tag: Short explanation of the commit

Longer explanation explaining exactly what's changed and why, whether
any external or private interfaces changed, what issue were fixed (with
issue number if applicable) and so forth. Be concise but not too brief.

Closes #1234

摘要行#

  • 对更改本身的总结，而不是问题或影响/好处（这部分放在描述中）。

  • 始终是一个句子，没有尾随句点（句号）。

  • 确保不超过 72 个字符；可以使用“&”代替“and”，使消息更短。

  • 使用祈使现在时。例如，使用“添加印地语翻译”而不是“添加了印地语翻译”。

  • 您可以在第一行前加上一个标签，以便更容易知道提交适用于模块的哪个部分。例如，在 设置模块 中，带有“sound: Fix label alignments”的提交显然适用于声音面板。

主要描述#

  • 对更改及其背后的原因的详细描述。将提交消息视为发送给开发人员（或您自己，六个月后）的电子邮件，详细说明 为什么 您更改了某些内容。无需指定 如何：那些需要知道的人可以同时查看代码更改和提交消息。

  • 每行不得超过 75 个字符。行数没有限制。

  • 使用正常的散文、标点符号和大小写。

  • 如果您使用 git revert 命令撤消提交，git 会生成一个默认提交消息，其中指定您正在撤消的提交的哈希值和提交消息，但这不足以知道 为什么 您要撤消它，因此请添加更多注释。

引用#

  • 如果您的提交正在解决一个问题，请使用 GitLab 语法 在将提交与上游仓库合并时自动关闭该问题

    Closes #1234
Fixes #1234
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1234

  • 代表他人提交代码时，请使用 --author 选项，并添加带有 --signoff 的 Signed-off-by 行

    git commit -a --author "Joe Coder <joe@coder.org>" --signoff