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 合并到默认存储库分支，它将自动关闭您的问题。
