约定式提交
提交消息准则
对于如何格式化 git commit 消息，我们有非常精确的规则。这会导致更具可读性的消息，在查看项目历史记录时易于遵循。而且，我们使用 git commit 消息生成 Angular 更改日志。
提交消息的格式
每个提交消息都包含一个标题，一个正文和一个页脚。标头具有一种特殊的格式，其中包括类型，范围和主题：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
标头是必需的，标头的范围是可选的。
提交消息的任何一行都不能超过100个字符！这使得该消息在 GitHub 以及各种 git 工具中更易于阅读。
页脚应包含对 问题的结尾引用 (如果有)。
样本(示例)
docs(changelog): 将变更日志更新为beta.5
fix(release): 需要依赖最新的 rxjs 和 zone.js
package.json 中的版本将复制到我们发布的版本中，并且用户需要其中的最新版本
还原
如果该提交恢复了先前的提交，则应以 revert: ，然后是还原提交的标题。在正文中应该说：This reverts commit <hash>., 其中哈希值是要还原的提交的 SHA 。
类型
必须为以下之一：
- build: 影响构建系统或外部依赖项的更改 (比如: gulp, broccoli, npm)
- ci: 对我们的 CI 配置文件和脚本的更改(比如: Circle, BrowserStack, SauceLabs)
- docs: 仅文档更改
- feat: 一个新功能
- fix: 一个 bug 的修复
- perf: 修改代码提高性能
- refactor: 既不修改 bug 也不新增功能的修改
- style: 不会影响代码含义的更改（空格，格式，缺少分号等）
- test: 添加缺失的测试或更正现有的测试
范围
作用域应该是受影响的npm软件包的名称（由读取从提交消息生成的变更日志的人所感知的）。
以下是受支持范围的列表：
- animations
- common
- compiler
- compiler-cli
- core
- elements
- forms
- http
- language-service
- platform-browser
- platform-browser-dynamic
- platform-server
- platform-webworker
- platform-webworker-dynamic
- router
- service-worker
- upgrade
当前，“use package name” (使用包名称)规则有一些例外：
- packaging: 用于更改所有软件包中的 npm 软件包布局的更改，例如公共路径更改，对所有软件包进行的 package.json 更改，d.ts 文件/格式更改，对包的更改等。
- changelog: 用于更新发行说明 CHANGELOG.md
- aio: 用于仓库的 /aio 目录中与 docs-app（angular.io）相关的更改
- none/empty string: 对
style有用，test和refactor
在所有软件包中进行的更改 (e.g.style: add missing semicolons)
标题（Subject）
该主题包含对变更的简洁描述：
- 使用
imperative/present tense: "change" not "changed" nor "changes" - 不要大写第一个字母
- 不要以 "." 结尾
正文（body）
与标题一样使用 imperative/present tense: "change" not "changed" nor "changes",z正文应包括改变的动机，并将其与以前的特性进行对比。
页脚（Footer）
页脚应包含有关 Breaking Changes (重大变化) 的所有信息，也是引用此提交关闭(commit Closes) 的GitHub问题的地方。
Breaking Changes 应以单词 BREAKING CHANGE: 用一个空格或两个换行符。然后，将其余的提交消息使用在这。
可以在 本文档 中找到详细说明。
浙公网安备 33010602011771号