在仓库中，我们使用并强制执行提交信息约定。这些约定使用 commitlint 和 Angular 配置 进行验证。
这些约定的原因： #
- 自动生成变更日志
- 简单地在 Git 历史记录中导航（例如，忽略样式更改）
提交信息的格式： #
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
提交信息示例： #
fix(middleware): ensure Range headers adhere more closely to RFC 2616
Add one new dependency, use `range-parser` (Express dependency) to compute
range. It is more well-tested in the wild.
Fixes #2310
消息主题（第一行） #
第一行不能超过 72 个字符，并且后面应紧跟一个空行。类型和范围应始终为小写，如下所示。
允许的<type>值： #
- feat 用于用户的新功能，而不是构建脚本的新功能。此类提交将触发版本发布，并增加次要版本。
- fix 用于用户的错误修复，而不是构建脚本的修复。此类提交将触发版本发布，并增加补丁版本。
- perf 用于性能改进。此类提交将触发版本发布，并增加补丁版本。
- docs 用于文档更改。
- style 用于格式更改，缺少分号等。
- refactor 用于重构生产代码，例如重命名变量。
- test 用于添加缺少的测试，重构测试；没有生产代码更改。
- build 用于更新构建配置、开发工具或其他与用户无关的更改。
<scope>值的示例： #
- init
- runner
- watcher
- 配置
- web-server
- proxy
- 等等。
<scope>可以为空（例如，如果更改是全局性的或难以分配给单个组件），在这种情况下，括号将被省略。在较小的项目（例如 Karma 插件）中，<scope>为空。
消息正文 #
就像在<subject>中一样，使用祈使句，现在时态：“更改”而不是“已更改”或“更改”。消息正文应包含更改的动机，并与之前的行为形成对比。
消息脚注 #
引用问题 #
已关闭的问题应在脚注中单独一行列出，并在前面加上“Closes”关键字，如下所示
Closes #234
或者在多个问题的情况下
Closes #123, #245, #992
重大更改 #
所有重大更改都必须在脚注中提及，并附带更改说明、理由和迁移说明。
BREAKING CHANGE:
`port-runner` command line option has changed to `runner-port`, so that it is
consistent with the configuration file syntax.
To migrate your project, change all the commands, where you use `--port-runner`
to `--runner-port`.
任何包含重大更改部分的提交都将触发主要版本发布，并独立于提交类型出现在变更日志中。
本文档基于 Angular 提交信息格式。请参阅 提交历史记录以获取格式正确的提交信息示例。