自己使用git进行管理项目代码时候,往往要通过 git commit -m "this is a test commit "命令来提交每次提交的信息来表明此次提交做了哪些的修改。
commit message 的好处
- 提供更多的历史信息,方便快速浏览。
- 可以过滤某些commit(比如文档改动),便于快速查找信息。
- 可以直接从commit生成Change log。
但是有个问题,这个提交信息原则是都是每次都要填的(不填不让提交),但也仅此而已,git不会限制你填的内容,格式,所以显而易见会出现各种各样,五花八门,只有想不到没有写不出的message。
所以对提交messgae添加更多的限制是很有必要的。
严格模式下的 commit message 格式
header
<type>(<scope>): <subject>
<空一行>
body
Body部分是对本次 commit 的详细描述,可以分成多行。下面是一个范例。
<空一行>
footertype:包含此次提交的类型
- feat:新功能(feature)
- fix:修补bug
- docs:文档(documentation)
- style: 格式(不影响代码运行的变动)
- refactor:重构(即不是新增功能,也不是修改bug的代码变动)
- test:增加测试
- chore:构建过程或辅助工具的变动
scope:包含此次提交影像的范围
比如数据层、控制层、视图层等等或者模块A,模块B,或者生产环境,配置文件等等,视项目不同而不同。
subject: 此次提交的简短描述
- 以动词开头,使用第一人称现在时,比如
change
,而不是changed
或changes
- 第一个字母小写
- 结尾不加句号(
.
)
但是对于很多项目而言,每个都用上这种严格的提交格式,或许有点麻烦,定义一个自己可以遵守的提交标准或许更加符合实际要求、不用强制校验,自己自觉遵守。
格式:type(scope) :description 表示:提交类型(范围):提交简短描述
type:
#主要使用type
- fix: 修复bug
- add: 新功能
#代码修改优化type
- refactor:重构(即不是新增功能,也不是修改bug的代码变动)
- style : 代码格式改变,不影响代码含义的改动,例如去掉空格、改变缩进、增删分号;
- test: 增加测试代码
#版本控制type
- revert: 撤销上一次的commit
- merge:合并分支
#开发环境type
- build: 构建工具或构建过程等的变动,如:gulp 换成了 webpack,webpack 升级等
scope:(可忽略)
表示此次提交影响的范围,比如按照功能分模块的某个功能,几个功能并列写出
description :
不超过50个字符。
推荐以动词开头,如: 设置、修改、增加、删减、撤销等
最后,给自己定下了标准就要遵守。。。。。20201125