程序员如何通过插件规范 Git commit message 的提交?
Git
相信大家在日常的工作中经常会使用到,在我们完成一个需求开发或者 bug
修复的时候都会将变动的代码文件进行 commit
提交到远程。
那么问题来了,仔细看下你的提交记录,里面是不是有很多 test
,fix
,update
,add
等等丝毫看不出任何含义的 commit message
。
commit message
的提交很多时候都只依赖开发人员的自我规范,而开发人员往往在需求紧急或者 bug
要及时修复的时候,根本不会花很多时间在写 git commit message
的信息。而且就算是写,每个人的风格也不一样,所以写出来的 message
也不完全相同。
这个时候我们就需要有一套规范了,现在业界比较常用的规范是的格式是这样的:type(scope):subject
,下面我们详细来聊一下。
Type
type
代表的是提交内容的一种类型,每一种类型都代表着不同的含义,具体的类型取值和含义如下:
-
feat
:表示开发一个新的需求特性; -
fix
:表示修复一个bug
; -
docs
:表示是针对文档的修改,并没有修改代码; -
style
:格式修改,不影响代码功能; -
refactor
:不是进行feat
和fix
的代码修改,重构功能; -
perf
:提升性能的代码修改; -
tes
t:添加测试代码或者修正已经存在的测试功能代码; -
build
:修改会影响构建或者依赖的代码; -
ci
:修改集成配置的文件或者脚本; -
chore
:一些不够影响到源码和测试文件的修改; -
revert
:针对之前的一个提交的revert
修改;
对于我们来说在写一个 git commit
的时候,要搞清楚当前提交的内容的真正含义是什么,从而选择正确的类型。此外还要求我们对于代码的修改需要尽量细粒度,话句话说就是尽量将一个大的改动进行拆分,根据适当的情况进行 git
提交,避免一次性提交太多的改动。
Scope
scope
表示的当次 git
提交的内容影响的范围,这个范围比较宽泛,比如可以是 DAO
层,Controller
层,或者是具有特定功能的比如 utils
工具模块,权限模块,数据模块等等,只要能跟自己的项目挂上钩,表达出修改的范围就行,如果涉及到的范围比较多的话,可以用 *
表示,并不强制要求。
Subject
subject
部分是最重要的 git commit message
的部分,也就是我们经常要写提交信息的部分,这一部分通常会一个言简意赅的信息描述,需要写出我们改动代码的原因。
上面的 type
,scope
,subject
三个部分是我们常用的部分,不过有些规范将 git
的提交规范定义为 Header
,Body
和 Footer
三个部分,而 type
,scope
,subject
三个属于 Header
的部分。
扩展
Header
部分也就是上面提到的三个部分,是每个 git
提交的基础内容;Body
部分则是更加详细的描述信息,用于完整记录代码的修改地方和逻辑;Footer
部分则会将本次提交的内容与具体的需求或者缺陷相关联,比如对应的需求地址是什么,或者修复的 Bug
缺陷是什么等。
IDEA 插件
上面的内容不多,但是要记下来的还是很繁琐的,特别是有时候我们很难记住所有的 type
类型,好在 IDEA
现在有一个插件,就是用来规范 git
提交模板的。
在 IDEA
的插件市场中安装 git commit template
,直接搜索安装,然后重启 IDEA
即可。
安装完成过后,在我们需求提交代码的时候,会出现这个按钮。
点击一下就可以看到下面这个页面,其中 short description
就是我们上面提到的 subject
,而 Long description
代表的就是 Body
部分,而下面的 Breaking changes
和 Closed issues
则代表的是 Footer
部分,在使用的过程中按需填入即可。
总结
有很多小伙伴就要问了,写那么详细有什么用?规范我们的提交记录,主要是为了能追溯代码历史,很多时候我们自己写的代码在时间长了以后都记不住,更不要说别人写的代码了,所以只能从流程和规范上面来帮助大家更好的记忆。
文章转载自公众号:Java极客技术