How to write commit message right

2020-07-10 15:39:00 809 13 分钟

对于怎么写Git Commit 信息,每个人都有自己的看法,每个团队也有自己的规定。这并没有一个明确的标准,今天也不是来讨论标准,而是介绍一个相对优雅的方式。

[ac7536f1f] update some files
[cdc6708ad] change style
[93d4b716d] remove css files
[dfb928e85] update readme

之前,我写提交信息的时候,只会写主题信息。可能这样写的弊端大家也看到了,之后会看这些message的时候,并不知道这些提交到底是什么功能的。甚至有偷懒的同学可能会直接这么写 [52a9e19] Update ,能看懂这个commit messageupdate什么吗?可能在过段时间,这位同学也不知道是提交的什么了。

对于Git Commit Message并明确的标准,但也有一些好的原则:

使提交信息业务相关

本文开头的第一个代码片段是我之前提交的提交记录,现在来看的话,我已经不知道我写了什么?如果要知道到底提交了什么,涉及哪些功能,也只有借助版本工具了。

提交信息和代码一样,不只是给自己看,也是给团队中其他人看的,同时也是对提交信息的注释。在我过往经历中,看到过很多小伙伴为了方便随便写提交信息。修复一个登陆问题,提交信息却只写了Fix bug。这就导致了对于代码的回溯和问题排查十分困难,时间久了甚至只能一个一个Commit的排查。要记住一点:提交信息不只是给自己看的,也是给团队看的

示例

使用

实现单点登陆接口

替代

实现新功能

有个小建议,大家可以在提交代码的时候,如果实在是想不到,可以直接使用需求描述作为提交信息。

提交信息中写明类型

先来对提交代码的原因进行分类,大致可以分为几类:新功能、代码升级或变更、Bug修复、文档编写、主题UI变更和测试用例。提交代码的原因不外乎就是这几种,所以现在给这些原因相应加上一个标识,就变成了如下列表。

  • Feat: 新功能
  • Upgrade:功能升级或代码变更
  • Fix: Bug修复
  • Doc: 文档或README编写
  • Style: 主题UI变更
  • Test:新增测试代码

示例

使用

Feat:实现单点登陆接口

替代

实现单点登陆接口

提交信息尽量简短

想象一下,如果一条提交信息有几十个甚至近百个字,是不是很累。作为一个能偷懒就偷懒的程序猿,当然不可能写这么长的提交信息的。只要在能够正确表达出本次提交所代表含义的情况下,字数尽量少,最好不超过50个字符

示例

使用

Feat:实现单点登陆接口

替代

实现单点登陆接口,并修改了Login.java...(此处省略100字)

篇幅原因,错误示例就用省略号(…)来代替。可以看到绿色示例已经正确能够表达本次提交的主题了,所以完全没有必要写这么多字。

必要时要写描述(Decription)

描述是对提交信息的补充说明或详细描述,这部分内容很少有同学会注意到。但有时候描述却也不可缺少,比如说当合并代码存在冲突的时候,提交者就有必要将发生冲突的文件写在描述信息里面。

描述信息可以分为多行,可以在第72个字符的地方进行换行。

示例

使用

Upgrade: Update meta

  • update contributors
  • update eslint
  • update jest
  • update webpack

替代

Upgrade: Update meta

尽量使用英文

有人会说中文本就是母语,为什么不建议使用中文。在团队开发中,使用中文能够表达的更清楚明白。且一个团队里面,并不是所有的人英文都很好,如果要使用英文则需要保证你写的提交信息其他人也能看懂,否则就会适得其反了。

大家或多或少都使用过Windows来进行开发,当使用过 cmd来查看git log的时候,中文是乱码的。这实在是太不友好,如果要正常显示还要一顿骚操作。这也就是为什么建议尽量使用英文了。

Cmd

其实还有一个原因,如果我们写一个开源项目的话,提交到GitHub上面就是面向全世界的开发者,那么提交信息使用英文就十分友好了(说不定项目就火了呢)。

英文信息格式

如果要使用英文,那么就得注意一下提交的文本格式。英文的大小写和符号有无都会影响提交信息的美观。那我们就要对英文格式做一些约束。

  • 语句的首字母使用大写字符
  • 语句结尾不要有句号(.)

示例

使用

Fix: Fix can't login bug

替代

Fix:修复不能登录的bug

知识共享署名4.0国际许可协议进行许可

· Git· 笔记· Git