|
约定式提交规范是一种基于提交消息的轻量级约定。 它提供了一组用于创建清晰的提交历史的简单规则； 这使得编写基于规范的自动化工具变得更容易。 这个约定与 SemVer 相吻合， 在提交信息中描述新特性、bug 修复和破坏性变更。
提交说明的结构如下所示：
<类型>[可选的作用域]: <描述>
[可选的正文]
[可选的脚注]
大致分为三个部分(使用空行分割):
- 标题行: 必填, 描述主要修改类型和内容
- 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
- 页脚注释: 放 Breaking Changes 或 Closed Issues
type
commit 的类型：
- feat: feature缩写，用户相关的新功能，构建脚本功能除外
- fix: 修改 bug
- perf: 更改代码，以提高性能（在不影响代码内部行为的前提下，对程序性能进行优化）
- refactor: 为了可读性或者性能，在不改变原有功能的前提下做的修改
- docs: 文档的变更
- style: 代码格式修改, 注意不是 css 修改（例如分号修改）
- test: 增加或重构了测试代码，但没有增加产品代码
- build: 影响项目构建或依赖项修改
- revert: 恢复上一次提交
- ci: 持续集成相关文件修改
- chore: 更新构建脚本，但是不会更新产品代码
- release: 发布新版本
- workflow: 工作流相关文件修改
scope
commit 影响的范围, 比如: route, component, utils, build…
subject
commit 的概述
body
commit 具体修改内容, 可以分为多行.
footer
一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.
提交说明包含了下面的结构化元素，以向类库使用者表明其意图：
- fix: 类型 为
fix 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 PATCH 相对应）。 - feat: 类型 为
feat 的提交表示在代码库中新增了一个功能（这和语义化版本中的 MINOR 相对应）。 - BREAKING CHANGE: 在可选的正文或脚注的起始位置带有
BREAKING CHANGE: 的提交，表示引入了破坏性 API 变更（这和语义化版本中的 MAJOR 相对应）。 破坏性变更可以是任意 类型 提交的一部分。 - 其它情况: 除
fix: 和 feat: 之外的提交 类型 也是被允许的，例如 @commitlint/config-conventional（基于 Angular 约定）中推荐的 chore:、docs:、style:、refactor:、perf:、test: 及其他标签。 我们也推荐使用improvement，用于对当前实现进行改进而没有添加新功能或修复错误的提交。 请注意，这些标签在约定式提交规范中并不是强制性的。并且在语义化版本中没有隐式的影响（除非他们包含 BREAKING CHANGE）。 可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如 feat(parser): adds ability to parse arrays.。
参考资料：https://www.conventionalcommits.org/zh-hans/v1.0.0-beta.4/
|