SAP 电商云 Spartacus UI 代码提交的 commit 信息规范

Commit Message Format

提交消息由标题、正文和可选的页脚组成。 提交消息中的每一行的最大长度为 100 个字符。

当您单击 Squash and merge 时，会出现两个文本字段。 第一个用于输入页眉，第二个用于输入正文和页脚，如下图所示：

下面是 header 的一个例子：

feat: introduce new facade signature and generic ngrx store state for fine-grained control of loading state (#124)

以下是相应的正文和页脚的示例。 页脚以 BREAKING CHANGE 开头。 请注意，正文和页脚由空行分隔：

The product, language and currency facades have been refactored. A generic reducer has been introduced for all entities that require fine-grained load, success and error state.

BREAKING CHANGE:

Product, language and currency facades have a new public interface.

Closes #123

header

提交标头是对已完成工作的简要总结。

当您单击 Squash and merge 时，会自动填充标题字段。 但是，它与我们的提交指南格式不完全匹配。 请修改它以适应以下格式：

类型是强制性的，并且必须是以下之一：

docs：仅用于对文档的更改

feat：用于新功能工作

fix：用于错误修复

perf：用于提高性能的代码更改

refactor：对于既不修复错误也不添加功能的代码更改

style：用于不影响代码含义的更改，例如空格、格式、缺少分号等

test：用于添加缺失的测试或纠正现有的测试。

chore：用于与构建、CI、脚本、配置以及不符合上述任何类型的任何内容相关的更改。

在 change log 里，我们只包含 feat 和 fix.

subject

主题包含对更改的简洁描述，并遵守以下规则：

主题是用现在时的祈使时态写的。 例如，“add facades”，而不是“adds facades”或“added facades”。

• 主题消息的第一个字母是小写的。
• 主题消息的末尾没有句点。

PR Number

在标题的末尾，在括号中包含 GitHub PR 编号，如下所示：(#124)。

默认情况下，GitHub 会在此处自动包含拉取请求编号，因此您无需手动添加。 提交提交信息后，GitHub 会将 PR 号转换为原始拉取请求的链接，这对于正在阅读变更日志的任何人来说都非常方便。

body

正文输入到标题字段下方的文本字段中。

以下是编写正文的一些准则：

描述您正在解决的问题。 无论您的补丁是单行错误修复，还是 5000 行新代码，都必须有一个潜在的问题促使您进行这项工作。 向审阅者明确修复的必要性，以便他们继续阅读。

从用户的角度描述这种变化的影响。 应用程序崩溃和锁定非常令人信服，但并非所有错误都那么明显； 这一信息应在案文中提及。 即使在代码审查期间发现了问题，也要描述您认为它可能对用户产生的影响。

描述您所做更改的技术细节。 尽可能清楚地描述更改非常重要。 这将帮助审阅者验证代码的行为是否符合您的预期。

footer

如果您的问题包含重大更改，请以 BREAKING CHANGE: 开始页脚：后跟空格或空行，然后是重大更改的描述。 您可以使用以下关键字在页脚中指示一项或多项重大更改：

• BREAKING CHANGE
• BREAKING CHANGES

如果您的问题包含弃用，您可以使用类似的方法来中断更改，并使用以下关键字：

• DEPRECATION
• DEPRECATED
• DEPRECATIONS

页脚也是您应该引用正在修复的问题的地方（例如，关闭 #123 或修复 #123）。 有关格式的信息以及可用关键字的列表，请参阅 GitHub 帮助。 此外，一旦您将 PR 合并到默认存储库分支，它将自动关闭您的问题。