前言

git作为一个开发人员必不可少的工具,代码提交也是日常一个非常频繁的操作,如果你或你的团队目前对提交信息还没有一个规范或约束,那么你有必要看看本文的内容了。

为什么要规范提交信息

首先规范提交信息肯定是有必要的,简单总结下几点好处:

  • 让项目的维护或使用人员能了解提交了哪些更改
  • 清晰的历史记录,可能某天自己就需要查到呢
  • 规范的提交记录可用于自动生成修改日志(CHANGELOG.MD)
  • 基于提交类型,触发构建和部署流程

使用什么规范

Conventional Commits(约定式提交规范),是目前使用最广泛的提交信息规范,其主要受AngularJS规范的启发,下面是一个规范信息的结构:

1
2
3
4
5
<type>[optional scope]: <subject>
//空一行
[optional body]
//空一行
[optional footer(s)]

规范说明

type 提交的类别,必须是以下类型中的一个

1
2
3
4
5
6
7
8
feat:增加一个新功能
fix:修复bug
docs:只修改了文档
style:做了不影响代码含义的修改,空格、格式化、缺少分号等等
refactor:代码重构,既不是修复bug,也不是新功能的修改
perf:改进性能的代码
test:增加测试或更新已有的测试
chore:构建或辅助工具或依赖库的更新

scope 可选,表示影响的范围、功能、模块

subject
必填,简单说明,不超过50个字

body
选填,用于填写更详细的描述

footer
选填,用于填关联issus,或BREAK CHANGE

BREAKING CHANGE

必须是大写,表示引入了破坏性 API 变更,通常是一个大版本的改动,BREAKING CHANGE: 之后必须提供描述,下面一个包含破坏性变更的提交示例

1
2
3
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

更详细的说明请看约定式提交规范

如何约束规范

怎么确保每个提交都能符合规范呢,最好的方式就是通过工具来生成和校验,commitizen是一个nodejs命令行工具,通过交互的方式,生成符合规范的git commit,界面如下:

开始安装:

1
2
3
4
5
6
# 全局安装
npm install -g commitizen
# 或者本地安装
$ npm install --save-dev commitizen
# 安装适配器
npm install cz-conventional-changelog

packages.json在配置文件中指定使用哪种规范

1
2
3
4
5
6
...
"config": {
"commitizen": {
"path": "cz-conventional-changelog"
}
}

安装完成后可以使用git cz 来代替git commit,然后根据提示一步步输入即可

格式校验commitlint

可能你不想每次都通过交互界面来生成,还是想使用git commit -m 'message',那么为了确保信息的正确性,可以结合husky对提交的信息进行格式验证

安装依赖

1
2
3
npm install --save-dev @commitlint/{config-conventional,cli}
# 安装husky
npm install --save-dev husky

添加 commitlint.config.js文件到项目

1
2
3
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
```
`package.json`配置

#git提交验证
“husky”: {
“hooks”: {
“commit-msg”: “commitlint -E HUSKY_GIT_PARAMS”
}
},

1
2

OK到这一步就完成了,最后给你项目README.MD加上一个`commitizen-friendly`的标识吧

Commitizen friendly

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

[![Commitizen friendly](https://img.shields.io/badge/commitizen-friendly-brightgreen.svg)](http://commitizen.github.io/cz-cli/)

## 自动版本管理和生成CHANGELOG

规范化的提交信息除了能很好描述项目的修改,还有一个很好的作用就是能根据提交记录来生成CHANGELOG.MD和自动生成版本号等功能。


### standard-version

一个用于生成`CHANGELOG.md`和进行`SemVer(语义化版本号)`发版的命令行工具

主要功能:
* 自动修改最新版本号,可以是`package.json`或者自定义一个文件
* 读取最新版本号,创建一个最新的`git tag`
* 根据提交信息,生成`CHANGELOG.md`
* 创建一个新提交包括 `CHANGELOG.md``package.json`


### 语义化版本控制(SemVer)

先简单了解下什么是语义化的版本控制,其是由`GitHub`发起的一份用于规范版本号递增的规则,
##### 版本格式
主版本号.次版本号.修订号,版本号递增规则如下:

* 主版本号(major):当你做了不兼容的 API 修改,
* 次版本号(minor):当你做了向下兼容的功能性新增,可以理解为Feature版本,
* 修订号(patch):当你做了向下兼容的问题修正,可以理解为Bug fix版本。

先行版本号可以加到“主版本号.次版本号.修订号”的后面,作为延伸。

##### 先行版本
当即将发布大版本改动前,但是又不能保证这个版本的功能 100% 正常,这个时候可以发布先行版本:

* alpha: 内部版本
* beta: 公测版本
* rc: 候选版本(Release candiate)

比如:1.0.0-alpha.0,1.0.0-alpha.1,1.0.0-rc.0,1.0.0-rc.1等。

`standard-version` 会根据提交的信息类型来自动更改对应的版本号,如下:
* feat: 次版本(minor)+1
* fix: 修订号(patch) +1
* BREAK CHANGE: 主板号(marjor) +1

> `standard-verstion` 生成的`CHANGELOG`只会包含`feat`,`fix`,`BREACK-CHANGE`类型的提交记录


#### 使用
``` bash
npm i --save-dev standard-version

添加npm script

1
2
3
4
5
6
7
{
scripts:{
"release": "standard-version",
"release:alpha": "standard-version --prerelease alpha",
"release:rc": "standard-version --prerelease rc"
}
}

执行:

1
2
3
4
# npm run script
npm run release
# or global bin
standard-version

或者你想指定发行版本号:

1
2
3
4
#指定类型 patch/minor/marjor
npm run release -- --release-as patch
#指定版本号
npm run release -- -- release-as 1.1.0
生命周期
  • prerelease:所有脚本执行之前
  • prebump/postbump: 修改版本号之前和之后
  • prechangelog/postchangelog:生成changelog和生成changelog之后
  • pretag/postag:生成tag标签和之后

standard-version本身只针对本地,并没有push才操作,我们可以在最后一步生成tag后,执行push操作,在paceage.json中添加

1
2
3
4
5
"standard-version": {
"scripts": {
"posttag": "git push --follow-tags origin master && npm publish"
}
}

还有更多配置功能自行查阅 官方文档

其它类似工具

除了standard-version,还有其它类似的工具,有兴趣可以去了解下

修改Git Commit

为了使CHANGELOG.MD更能加直观看到每个版本的修改,我们尽量保证每次提交都是有意义的,但实际开发过程中,不可避免会提交了一些错误的commit message,下面介绍几个git命令来修改commit

1 修改最后一次提交

git commit --amend

该命令会创建一个提交并覆盖上次提交,如果是因为写错或者不满意上次的提交信息,使用该命令就非常适合。

2 合并多条提交

git reset --soft [commitID]

如果你想合并最近几条提交信息的话,那么就需要使用上面的命令来操作,指定要撤销的ccommitId,该命令会保留当前改动并撤销指定提交后的所有commit记录,如果不指定ID的话可以使用HEAD~{num} 来选择最近{num}条提交

1
2
git reset --soft HEAD~2 #合并最近两条提交
git commit -m 'feat: add new feat'

--soft 参数的区别在于把改动内容添加到暂存区 相当于执行了git add .

git rebase -i

git rebase的功能会更加强大,如果我想修改最近3条提交记录,执行

1
git rebase -i  HEAD~3

会出现如下编辑器界面(vim编辑器):

上面显示的是我最近3条提交信息 ,下面是命令说明,
修改方式就是将commit信息前的pick改为你需要的命令,然后退出:wq保存

下面是常用的命令说明:

1
2
3
4
5
6
p,pick = 使用提交
r,reword = 使用提交,但修改提交说明
e,edit = 使用提交,退出后使用git commit --amend 修改
s,squash = 使用提交,合并前一个提交
f,fixup = 和squash相同,但丢弃提交说明日志
d,drop = 删除提交,丢弃提交记录

最后

文本主要介绍了如何规范git commit和自动语义化版本管理,以及如何修改git commit,遵循一个规范其实没比之前随意填写信息增加多少工作量,但依赖规范却可以实现更多提升效率的事情。

参考

感谢您的阅读,本文由 凹凸实验室 版权所有。如若转载,请注明出处:凹凸实验室(https://aotu.io/notes/2020/09/10/git-commit-control/