【开发规范】Git Commit 规范

<类型>[可选 范围]: <描述>
[可选 正文]
[可选 脚注]

大致分为三个部分（使用空行分割）：

1. 标题行：必填, 描述主要修改类型和内容
2. 主题内容：描述为什么修改, 做了什么样的修改, 以及开发的思路等等
3. 页脚注释：放 Breaking Changes 或 Closed Issues

提交类型：

• feat: 新功能、新特性
• fix: 修改 bug
• perf: 更改代码，以提高性能（在不影响代码内部行为的前提下，对程序性能进行优化）
• refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
• docs: 文档修改
• style: 代码格式修改, 注意不是 css 修改（例如分号修改）
• test: 测试用例新增、修改
• build: 影响项目构建或依赖项修改
• revert: 恢复上一次提交
• ci: 持续集成相关文件修改
• chore: 其他修改（不在上述类型中的修改）
• release: 发布新版本
• workflow: 工作流相关文件修改

影响范围：说明此次提交的代码对目前工程功能所影响的范围，例如：所涉及到的功能模块

提交描述：说明此次提交的具体描述概述信息。

描述正文：commit 具体修改内容, 可以分为多行，详细描述此次提交的修改内容。（可选部分内容）

提交脚注：一些备注，通常是BREAKING CHANGE 或修复的 bug 的链接。

"Breaking change"（翻译为“破坏性变更”）是指在软件开发中对现有功能或接口进行的修改，这种修改可能导致现有的代码、功能或者接口无法与之前的版本兼容。这种变更可能会打破依赖于原有行为的代码，因此称之为“破坏性变更”。

提交详细说明：

参考文档：https://www.conventionalcommits.org/zh-hans/v1.0.0-beta.4/

• 每个提交都必须使用类型字段前缀，它由一个名词组成，诸如 feat 或 fix ，其后接一个可选的作用域字段，以及一个必要的冒号（英文半角）和空格。
• 当一个提交为应用或类库实现了新特性时，必须使用 feat 类型。
• 当一个提交为应用修复了 bug 时，必须使用 fix 类型。
• 作用域字段可以跟随在类型字段后面。作用域必须是一个描述某部分代码的名词，并用圆括号包围，例如： fix(parser):
• 描述字段必须紧接在类型/作用域前缀的空格之后。描述指的是对代码变更的简短总结，例如： fix: array parsing issue when multiple spaces were contained in string.
• 在简短描述之后，可以编写更长的提交正文，为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
• 在正文结束的一个空行之后，可以编写一行或多行脚注。脚注必须包含关于提交的元信息，例如：关联的合并请求、Reviewer、破坏性变更，每条元信息一行。
• 破坏性变更必须标示在正文区域最开始处，或脚注区域中某一行的开始。一个破坏性变更必须包含大写的文本 BREAKING CHANGE，后面紧跟冒号和空格。
• 在 BREAKING CHANGE: 之后必须提供描述，以描述对 API 的变更。例如： BREAKING CHANGE: environment variables now take precedence over config files.
• 在提交说明中，可以使用 feat 和 fix 之外的类型。
• 工具的实现必须不区分大小写地解析构成约定式提交的信息单元，只有 BREAKING CHANGE 必须是大写的。
• 可以在类型/作用域前缀之后，: 之前，附加 ! 字符，以进一步提醒注意破坏性变更。当有 ! 前缀时，正文或脚注内必须包含 BREAKING CHANGE: description