Git代码的提交规范
前言
我们在使用git进行提交代码的时候，相信很多同学和我之前一样，随便commit一下本次的更改需求以及描述说明。我个人认为其实也没啥，自己看得懂就完了，对不！
是的，自己看懂没问题。问题的出现在当你协同合作或者提交的时候，别的大佬看不懂啊！ 主管、总监等就连前台的小姐姐也得diss你一句，你这提交的啥。为了避免尴尬还是规范一点比较好。
一、git commit 的规范模版组成
基础的组成形式是由header、body和footer组成， 他们组成的commit格式如下
<header>
空一行
<body>
空一行
<footer>
header（必填）
基本格式：type(scope):subject
- type(必填):类型 feat ==》 新功能
- scope(可填):范围 登录模版、xxx功能块等，就是那个模版范围进行了调整
- subject(必填):简述 建议不要超过30个字
指令如下
feat(login模块): 登录功能已开发完毕
主要还是讲讲type(类型)这一块，以下是常用的type
| 属性 | 描述 | 例子 |
|---|---|---|
| feat | 新功能 | feat(管理模版): 新增员工管理 |
| fix | 修改bug | fix(管理模版): 修复员工管理无权限的问题 |
| docs | 文档修改 | docs(swagger): swagger-api更新 |
| style | 代码风格相关 | style(system): 统一使用prettier |
| refactor | 代码重构 | refactor(登录模版): 简化登录的流程 |
| perf | 性能提升 | perf(table模版): 优化table表格数据过多的问题 |
| test | 测试 | test(登录模版)：为登录模版做了单元测试等 |
| build | 影响构建系统或者外部依赖的修改(npm、webpack、xxx.yaml等) | build(webpack): 更新webpack |
| ci | 对配置文件或者脚本进行修改 | |
| chore | 修改构建流程、或者增加依赖库、工具等 | chore: 更新node的版本 |
| revert | 回退版本 | revert: 回退到xxx版本 |
body（非必填）
详细说明本次commit修改的内容
- 员工管理新增功能
- 员工管理删除功能
- 员工管理修改功能
- 员工管理权限的添加
footer（非必填）
主要用于关联 Issue、描述破坏性变更（BREAKING CHANGE）等。
BREAKING CHANGE: 旧版员工权限接口已废弃，需迁移至 /api/v2/manage
Closes #1024
完整的如下
feat(管理模版): 新增员工管理
- 员工管理新增功能
- 员工管理删除功能
- 员工管理修改功能
- 员工管理权限的添加
Closes #1024
业余时间做的一个小程序，可以探讨全栈(nestjs、flutter、小程序)相关问题
