GIT释规范推荐
为什么需要规范
无规矩不成方圆,编程也一样。
如果你有一个项目,从始至终都是自己写,那么你想怎么写都可以,没有人可以干预你。可是如果在团队协作中,大家都张扬个性,那么代码将会是一团糟,好好的项目就被糟践了。不管是开发还是日后维护,都将是灾难。
这时候,有人提出了何不统一标准,大家都按照这个标准来。于是 ESLint,JSHint 等代码工具如雨后春笋般涌现,成为了项目构建的必备良品。
Git Commit 规范可能并没有那么夸张,但如果你在版本回退的时候看到一大段糟心的 Commit,恐怕会懊恼不已吧。所以,严格遵守规范,利人利己。
具体规则
先来看看公式:
<type>(<scope>): <subject>
type(必须)
用于说明 commit 的类别,只允许使用下面10个标识。
- feat:新功能(feature)
- alter: 修改代码(逻辑,流程)
- helper: 增加辅助功能代码
- fix:修补bug
- docs:文档(documentation)
- style: 格式(不影响代码运行的变动)
- refactor:重构(即不是新增功能,也不是修改bug的代码变动)
- test:增加测试
- deploy:构建过程,部署
- optimize: 优化代码
subject(必须)
用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。
是 commit 目的的简短描述,不超过50个字符。
- 以动词开头,使用第一人称现在时,比如change,而不是changed或changes
- 第一个字母小写
- 结尾不加句号(.)
提示
某公司内部标准,记录下来,方便自己参考