git commit 提交规范_git commit fix

约定式提交规范是一种基于提交消息的轻量级约定。 它提供了一组用于创建清晰的提交历史的简单规则； 这使得编写基于规范的自动化工具变得更容易。 这个约定与 SemVer 相吻合， 在提交信息中描述新特性、bug 修复和破坏性变更。

提交说明的结构如下所示：

---

<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的脚注]
1
2
3
4
5

大致分为三个部分(使用空行分割):

1. 标题行: 必填, 描述主要修改类型和内容
2. 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
3. 页脚注释: 放 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 的链接.

提交说明包含了下面的结构化元素，以向类库使用者表明其意图：

1. fix: 类型 为 fix 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 PATCH 相对应）。
2. feat: 类型 为 feat 的提交表示在代码库中新增了一个功能（这和语义化版本中的 MINOR 相对应）。
3. BREAKING CHANGE: 在可选的正文或脚注的起始位置带有 BREAKING CHANGE: 的提交，表示引入了破坏性 API 变更（这和语义化版本中的 MAJOR 相对应）。 破坏性变更可以是任意 类型 提交的一部分。
4. 其它情况: 除 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/