如何既不冗余繁琐,又规范地提交git的commit信息。

学习本篇前,你必须具备以下知识储备:

  • 熟悉使用git命令行

事情起因是入职至今已接近一年,项目和架构管理都没有对git的commit信息做过统一的规范管理。而前端在只有我一个人工作的情况下也容易出现不需要协同合作所以对于提交信息不是太在意的情况。

于是乎搜索整理了一通,网上不乏有许多的提交规范,以及规范插件如Commitizen。整理后发现其实对于这些东西对于新手存在一定冗余,对于老手更是没有什么意义。

所以觉得,统一好提交规范即可。而这里以使用推广最为广泛的Angular规范为例。


commit message格式

commit message结构

标准的commit message的结构分为三段:header,body,footer

1
2
3
4
5
6
// header(重要)
<type> (<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

而无论哪一个结构哪一行,都应该在一行内不超过50个字符

header为最重要的,也是必须的,而body和footer则可以省略。

其中type为commit类型,截止至目前,共允许一下几种标识:

最常用的type

  • feat(feature): 新功能
  • fix:功能修补

其他的type

  • docs:对文档的改动,如readme,或者博客
  • style:不影响代码含义的改动,如空格缩进分号等的删减
  • build:对于构建器或者依赖的改动,如webpack或者npm
  • refactor:重构代码时的改动,注意:重构代码为不改变功能情况下对代码的修改,否则功能只要有所变更,都应该属于fix

不常用的type

  • revert:执行git revert打印的message
  • test:跟测试有关的代码改动
  • pref:提高性能的改动
  • ci:对于持续集成服务的改动
  • chore:不修改src或者test的其他改动,如构建过程和辅助工具变更

对于scope,官网中是这么说的:

The scope should be the name of the npm package affected (as perceived by the person reading the changelog generated from commit messages.

即新增或者受影响组件或者文件名,如以下示例:

  • animations
  • common
  • compiler
  • compiler-cli
  • core
  • elements
  • forms
  • http
  • language-service
  • platform-browser
  • platform-browser-dynamic
  • platform-server
  • platform-webworker
  • platform-webworker-dynamic
  • router
  • service-worker
  • upgrade

对于subject描述,有三个规则:

  • 以动词开头,使用第一人称现在时
  • 第一个字母小写
  • 结尾不加句号(包括英语句号.)

所以,你的commit信息应该这么写:

1
git commit -m 'feat(shopCar):add shopCar component';

body

body是对commit的详细描述,可分成对行,可省略

用以说明代码的变动的动机,以及和以前的对比。

一般适用于refactor项目重构等说明。

1
2
3
4
5
6
7
More detailed explanatory text, if necessary.  Wrap it to 
about 72 characters or so.

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Use a hanging indent

footer适用于以下两种情况,一种是有BREAKING CHANGE,并且以此为开头为开头。

然后说明对变动的描述理由和方法。

一种是对issue的关闭

具体情况可以到阮一峰的博文中进行了解。


尾声

对于日常的工作内容,其实不需要用到辅助的Commitizen等插件,如果严格规范的话可以使用一下。

对于中英文的问题,我的建议是英文>中文,

同时对一个团队项目内的git log保持语言的一致

有以下三条相关链接比较推荐阅读:

评论