持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第13天，点击查看活动详情
在使用 Git 的时候，良好的提交代码规范可以清晰地看到每次代码的提交历史以及变更，便于对项目进行维护.在需要版本回退时，也可以快速定位到需要回退的版本。
格式
一个完整的提交格式包含三部分：标题行 + 主题内容 + 页脚注释
具体如下：
<type>(<scope>): <description>
<body>
<footer>
举个例子：
fix(组件1): 修改公用组件1逻辑
修改了某某问题
删除某些多余的引用
closes #001 // 关闭了某个bug
在实际的开发过程中，往往会使用简化版本（除非有明确的规范要求）
git commit -m 'feat: 描述'
header
header 表示标题行，header 部分包括 type、scope、subject 三部分，其中，type、description 为必填字段，scope 为可选字段。
type：用于说明本次提交的类型scope：表示范围，也就是当前修改的领域，比如页面、模块或是功能的名称description: 本次修改的内容的简单描述
type
- feat: 新功能（feature的缩写）
- fix: 修补bug
- docs: 文档（documentation的缩写）
- style: 样式变化
- refactor: 重构（并未新增功能）
- chore: 构建过程或辅助工具的变动
- revert: 撤销，版本回退
- perf: 性能优化
- test：测试
- improvement: 改进
- build: 打包
- ......
一般来说，使用 feat、fix 相对会较多一些。
body
body 表示主题内容，在 body 中会对这一次的提交进行详细的描述
footer
footer 表示页脚注释，使用 footer 一般只涉及到如下两种场景：
- 与上一版本不兼容的变动
- 关闭 bug 或者需求
场景1：在footer的位置，开头会写 BREAKING CHANGE，后面对变动进行描述（变动理由、实现方式等等）。
如：
BREAKING CHANGE: 升级项目，由Vue2.0 升级为 Vue3.0版本
情况2：
closes 001
不建议的写法
根据上面所述的规范，在开发过程中可以尽量写的规范一些，尽量避免如下这种形式的 commit
fix a bug
