# Git 提交规范

::: details 目录
[[toc]]
:::

## 意义

::: tip
代码需要编程规范，提交也需要说明规范。

简明扼要的提交说明能让自己和他人快速的了解每一次提交都对代码做了哪些重要变动。

混乱或无意义的提交说明只能降低效率并给人带来不严谨的坏映象。
:::

## 提交格式

```gitignore
[module]:<type>(<scope>)> <subject>
```
`module` 模块
`type` 则定义了此次变更的类型，只能使用下面几种类型:

| Type            | 说明           |
| :-------------: |-------------|
| feat            | 增加新功能      |
| fix             | 修复问题/BUG    |
| style           | 代码风格相关无影响运行结果的  |
| perf            | 优化/性能提升    |
| refactor        | 重构            |
| revert          | 撤销修改 |
| test            | 测试相关 |
| docs            | 文档/注释 |
| chore           | 依赖更新/脚手架配置修改等 |
| workflow        | 工作流改进 |
| ci              | 持续集成 |
| types           | 类型定义文件更改 |
| wip             | 开发中 |

`scope` 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等。
`subject` 是对变更的简要描述。

```gitignore
#单模块提交
base:fix> 更新

#多模块提交
[base,big,graph]:fix> 更新

#影响范围示例
feat(compiler): 添加平面图编辑器的绘制和点选
fix(v-model): 处理失焦事件
perf(core): 通过删除'foo'改善虚拟dom存在的差异

#该bug若有编号，eg：#3055，带入当前编号
fix(v-model): close #3055 ，平面图编辑器备注

```

## .gitignore
```gitignore
.DS_Store
node_modules
/dist
package-lock.json

# local env files
.env.local
.env.*.local

# Log files
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*

# Editor directories and files
.idea
.vscode
*.suo
*.ntvs*
*.njsproj
*.sln
*.sw?
```
## 约定
* 少修改，多提交。尽可能每改一个要点就提交一次，这样提交说明也能容易描述。也便于出问题时代码回退。“提交”的概念是具有独立的功能、修正等作用。 小可以小到只修改一行，大可以到改动很多文件， 但划分的标准不变，一个提交只解决一个问题的。
* 简明扼要，不要写的太详细，最好一行搞定，要一目了然，详细信息可以查看代码差异。
* 如果确实需要一些较长内容的说明，则第一行简明扼要，第二行空行，从第三行起开始详细说明。