conventional commit
介绍
conventional commit，约定式提交规范，是一种基于提交信息的轻量级约定，提供了一组简单规则来创建清晰的提交历史
提交说明的结构如下所示：
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]元素
提交说明包含以下元素，向类库使用者/审查者表明意图
- fix：type，表明修复了代码库中的一个bug
- feat：type，表明新增了一个功能
- BREAKING CHANGE：表示引入了破坏性变更，在脚注(footer)中，或者在type后加一个
! - 其他type：
- build：用于修改项目构建系统
- chore：用于对非业务性代码进行修改，例如修改了工具配置等
- ci：用于修改持续集成流程，如工作流等
- docs：用于修改文档，例如对README进行修改
- style：用于修改代码的样式，如缩进等修改
- refactor：用于重构代码，指修改了变量名/函数名/类名等，但是代码逻辑并未变化
- perf：用于优化性能，例如占用内存更少/执行更快
- test：用于修改测试用例
示例：
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files这是一个包含了描述以及破坏性变更脚注的说明 规范详情可见地址
目的
为什么要使用约定式提交？
- 自动化生成 CHANGELOG
- 基于提交的类型，自动决定语义化的版本变更
- 向同事、公众与其他利益关系者传达变化的性质
- 触发构建和部署流程
- 让人们探索一个更加结构化的提交历史，以便降低对你的项目做出贡献的难度
[! INFO] 在vscode有一个同名插件，可以尝试一下
内容
- 每个提交必须使用类型字段前缀，其后接可选的范围字段，以及必要的冒号和空格
- 当一个提交为应用或类库实现了新功能时，必须使用
feat类型 - 当一个提交为应用修复了 bug 时，必须使用
fix类型 - 范围字段可以跟在类型字段后面，范围必须是一个描述某部分代码的名词
- 在简短描述后，可以编写一个较长一个的正文，正文必须起始于描述字段结束的一个空行后
- 在正文结束的一个空行后，可以编写脚注，脚注必须包含一个令牌（token），后面紧跟
:<space>或<space>#作为分割符，后面再紧跟令牌的值 - 脚注的令牌必须使用
-作为连字符，除了BREAKING CHANGE - 破坏性变更必须在提交信息中标记出来，要么在<类型>(范围) 前缀中标记，要么作为脚注的一项
- 包含在脚注中时，破坏性变更必须包含大写的文本
BREAKING CHANGE，后面紧跟着冒号、空格，然后是描述 - 包含在<类型>(范围) 前缀时，破坏性变更必须通过把
!直接放在:前面标记出来 BREAKING-CHANGE作为脚注的令牌时必须是BREAKING CHANGE的同义词- 只有
BREAKING CHANGE必须是大写的