GIT注释规范推荐

GIT释规范推荐

为什么需要规范

无规矩不成方圆，编程也一样。

如果你有一个项目，从始至终都是自己写，那么你想怎么写都可以，没有人可以干预你。可是如果在团队协作中，大家都张扬个性，那么代码将会是一团糟，好好的项目就被糟践了。不管是开发还是日后维护，都将是灾难。

这时候，有人提出了何不统一标准，大家都按照这个标准来。于是 ESLint，JSHint 等代码工具如雨后春笋般涌现，成为了项目构建的必备良品。

Git Commit 规范可能并没有那么夸张，但如果你在版本回退的时候看到一大段糟心的 Commit，恐怕会懊恼不已吧。所以，严格遵守规范，利人利己。

具体规则

先来看看公式：

<type>(<scope>): <subject>

type（必须）

用于说明 commit 的类别，只允许使用下面10个标识。

1. feat：新功能（feature）
2. alter: 修改代码(逻辑,流程)
3. helper: 增加辅助功能代码
4. fix：修补bug
5. docs：文档（documentation）
6. style： 格式（不影响代码运行的变动）
7. refactor：重构（即不是新增功能，也不是修改bug的代码变动）
8. test：增加测试
9. deploy：构建过程,部署
10. optimize: 优化代码

subject（必须）

用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

是 commit 目的的简短描述，不超过50个字符。

1. 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
2. 第一个字母小写
3. 结尾不加句号（.）

提示

某公司内部标准，记录下来，方便自己参考