你见过最奇葩的代码提交信息是什么？别再为写commit message头疼了！

时间 2019-11-05

标签见过奇葩代码提交信息什么别再 commit message 头疼繁體版

原文原文链接

写在前面

对一个developer来讲，有时候变量命名，提交代码时的提交信息会让人很头疼，本文主要聊聊怎么优雅的书写commit message。前端

你见过最奇葩的代码提交信息是什么？

曾在上家公司的一个项目中，见过我至今以来见过最奇葩的代码提交信息，让我至今难忘。那个项目的前三个commit记录的提交信息分别是：git

First Blood

Double kill

Triple kill
复制代码

简直让人哭笑不得，不知道那位仁兄是否是在一边写代码一边开黑。你是否也见过什么样的奇葩的commit message呢？！github

这样的提交信息，不只没法告知其余人以前提交了什么内容，并且会让以为很不认真很不专业。npm

那规范的commitmessage能给咱们带来哪些好处呢？json

规范commit message的好处

可读性好，根据commit信息就能明确知道本次提交的修改内容及影响范围bash
能够根据不一样的提交类型，过滤掉不想关注的提交，提升效率app
能够自动化生成changeLog，甚至能够自动更新语义话的版本框架
能够下降codereview的沟通成本electron
一份清晰规范的commit messge，可让你表现的更专业工具

那么什么样的commit message才算是好的呢？咱们来看看在业界被不少人认同的两种提交风格。

Angular规范

Angular 的commit信息由标题，正文和页脚三个部分组成，每一个部分中间经过空行分隔。标题部分包括类型，范围和主题三个部分。

<type>(<scope>): <subject><BLANK LINE>
<body>
<BLANK LINE><footer>
复制代码

type 提交类型

提交的类型必须是下面的一个：

feat：增长一个新功能

fix：修复bug

docs：只修改了文档

style：作了不影响代码含义的修改，空格、格式化、缺乏分号等等

refactor：进行代码重构，既不是修复bug，也不是新功能的修改

perf：改进性能的代码

test：增长测试或更新已有的测试

chore：构建或辅助工具或依赖库的更新

scope 范围

说明当前提交的代码影响的范围，若是当前更改影响的不止一个范围时，可使用*

subject 描述

包含对变动的简洁描述: 使用祈使句，如今时态:"change"而不是"changed"或"changes"，第一个字母不要大写, 末尾没有点(.)

body 正文

使用祈使句，body应该包括为何修改，具体修改了哪些了东西。

footer 页脚注释

用来放置 Breaking Changes 或 Closed Issues

Conventional Commits 规范

基于Angular的提交规范衍生出的规范，很大程度上以其为Augular的规范为依据提交格式与Augular基本一致

<type>[optional scope]: <description>
[optional body]
[optional footer]
复制代码

type 提交类型

类型是必须提供的，且必须是名词，其后接一个可选的做用域字段，以及一个必要的冒号（英文半角）和空格；

提交新功能或新特性时，必须使用feat类型；
修复了 bug 时，必须使用fix类型；
可使用 feat 和 fix 以外的类型;

scope 范围

做用域必须是一个描述某部分代码的名词，并使用圆括号

description 描述

描述是必须项，字段必须紧接在类型/做用域的空格以后。描述指的是对代码变动的简短总结

body 正文

正文可可选的，若是书写必须起始于描述字段结束的一个空行后

footer

正文结束的一个空行以后，能够编写一行或多行脚注

BREAKING CHANGE

不兼容更新必须标示在正文区域最开始，或脚注区域中某一行的开始，必须包含大写的文本BREAKING CHANGE，后面紧跟冒号和空格。

在 BREAKING CHANGE: 以后必须提供描述，以描述对 API 的变动。例如：BREAKING CHANGE: environment variables now take precedence over config files.

能够在类型/做用域前缀以后，: 以前，附加 ! 字符，以进一步提醒注意不兼容变动。当有 ! 前缀时，正文或脚注内必须包含 BREAKING CHANGE: description

Conventional Commits规范是和SemVer规范（语义化版本）的约定是吻合的。

SemVer 是一套语义化版本控制的约定，定义的格式为 ** X.Y.Z（主版本号.次版本号.修订号）** ：

X.主版本号：进行不向下兼容的修改时，递增主版本号

Y.次版本号: 作了向下兼容的新增功能或修改

Z.修订号：作了向下兼容的问题修复

Conventional Commits规范是和SemVer规范相吻合的目的是什么呢？！咱们能够根据commit的类型去自动化的生成语义化的版本。

咱们比较熟知 electron 项目就采用了Conventional Commits规范，其余采用了这套规范的开源项目还有：

yargs：广受欢迎的命令行参数解析器。
istanbuljs：一套为 JavaScript 测试生成测试覆盖率的开源工具和类库。
uPortal-home 和 uPortal-application-framework：用于加强 Apereo uPortal 的可选用户界面。
massive.js：一个用于 Node 和 PostgreSQL 的数据访问类库。
scroll-utility：一个居中元素和平滑动画的滚屏工具包实例。
Blaze UI：无框架开源 UI 套件。
Monica：一个开源的人际关系管理系统。

相关工具

有了规范是好事，但不想记那么多的type怎么办？又怎么保证团队每一个成员真的按照规范去执行呢？这些均可以经过工具来解决。

Commitizen

一款帮助咱们按照规则去提交提交代码的懒人工具，它是一个通用的工具，提供了多种commit Message风格能够选择，好比咱们上面提到的Conventional规范，就能够经过按照 cz-conventional-changelog 来实现。

除了提供了一些可选的风格，还支持根据已有的规范去更改建立一套属于本身团队的风格配置。

安装：

npm install commitizen -g
复制代码

选择风格：

commitizen init cz-conventional-changelog --save-dev --save-exact
复制代码

commitizen init cz-conventional-changelog --yarn --dev --exact
复制代码

提交代码时，使用git cz 代替 git commit，每一步都会有提示，保证按照规范提交。

commitlint

commit message 的 linter，用来对 message 进行检查，防止提交了不符合规范的提交信息。

能够结合 git hooks 在提交commit时进行自动检查，不符合规范的commit不容许提交。

一样的，commitlint也支持配置安装不一样风格的配置，同时，你也可以发布并使用本身的配置。

安装：

npm install --save-dev @commitlint/{config-conventional,cli}
复制代码

配置风格

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
复制代码

结合git hooks使用

先安装husky

npm install --save-dev husky
复制代码

package.json中增长配置

{
"husky":{
  "hooks": {"commit-msg": "commitlint -E HUSKY_GIT_PARAMS" }       
   }
}
复制代码

这样在输入不符合风格的commit Message会没法经过，并会给出具体的提示。

standard-version

standard-version须要使用Conventional Commits规范，可以帮助自动生成符合SemVer规范的版本和 CHANGELOG。

安装：

npm i --save-dev standard-version
复制代码

package.json中增长配置：

{"scripts": {"release": "standard-version" }}
复制代码

第一次发布版本，执行命令，同时生成changeLog

npm run release -- --first-release
复制代码

以后版本变动，直接执行

npm run release
复制代码

常见问题

一次提交多种类型怎么操做

尽量拆分的task，每完成一部分就进行一次提交，避免一次提交过多的代码。这样可以避免一次commit修改过多文件，致使后续的维护，回退等的困难。

若是真的有这样的提交，能够选择最重要改动的type，在body部分详细写明具体的改动。

提交了不规范的信息怎么处理

若是使用了Commitizen或commitlint，基本上能够保证提交符合规范的Message，可是也可能出现选错了类型的问题，好比是新增的功能，可是一手抖，选成了fix并完成了commit，这时可使用 git rebase -i 来编辑提交历史。

参考

Angular规范：github.com/angular/ang…

Conventional Commits 规范： www.conventionalcommits.org/en/v1.0.0-b…

SemVer规范： semver.org/

欢迎关注个人公众号「前端小苑」，我会按期在上面更新原创文章。