规范git commit message与自动化版本控制

git commit message是你对你所编码内容的总结概括。规范、详细的git commit message不仅能体现你的内容概括能力,还能为你自己和团队,或项目带来巨大的好处,这也是我所推崇的。但很多小伙伴不愿意花时间在这里,经常会写出优化了一些功能修复了一些BUG等等模糊不清的commit message,完全没有意识到这么写会带来一些严重的问题:

  • 管理者/其他项目参与者无法快速获取有用信息,判定修改内容,只有花大量时间阅读源码;
  • 事后无法快速定位以前遇到的类似问题;
  • 无法自动化版本控制,只有每次重新阅读代码,手动写一些详细的描述,用来发布新版或提交测试。

规范、详细的git commit message不仅能解决这些问题,还能带来更多的好处。

  • 提供详细的历史信息,方便快速浏览,不用花大量时间阅读源码;

  • 提供高效的团队合作,参与者能从提交信息中看到项目的进度;

  • 可以快读定位问题,如果现在出现一个BUG,可以从BUG的类型,通过提交信息快读定位可能是哪次修改带来的;

  • 可以直接从commit中总结周报,日报,项目报告;

  • 可以直接从commit生成CHANGELOG;

  • 影响团队其他成员,培养大家养成良好的习惯。

下面我们推荐一个git commit message书写规范,以及如何通过commit message自动完成版本控制,生成CHANGELOG。

规范

我们严格遵循Conventional Commits 的约定,详细内容可以点击链接查看,下面我们简单总结一下。

commit messge格式如下:

1
2
3
4
5
<type>[optional scope]: <description>

[optional body]

[optional footer]

我们先举几个例子,再详细解析这个格式,如下:

1
2
3
4
5
6
feat(xxx): 新增了xxx功能,实现了xxx 
BREAKING CHANGE: 我们需要切换到V2了
fix(comment): 修复多用户评论时,顺序错乱问题
feat(comment): 新增用户评论功能
chore(comment): 新增了评论部分的swagger文档
docs(readme): 创建README.md文件

是不是不用我解释就懂了,对的就这么简单:

  • <type> : 是指本次提交的类型,一般有feat,fix,chore,docs,style,refactor,perf,test等,这里我推荐使用feat,fix,chore,docs四个,也就先说明这几个,更多的看这里
    • feat: 说明本次提交的是一个新的feature;
    • fix: 修复了一个bug;
    • chore: 一些没有构成feature, 但又不是其他类型的提交;
    • docs: 只是修改了文档相关的内容。
  • [optional scope]: 从单词的意思我们不难看出, 这里可以选填一个范围,也就是说,我们可以通过该关键词说明本次提交影响的范围(或许是一个模块,某一个功能,某一个业务等)。
  • <description> : 这里就是我们需要详细的描述本次提交内容的部分了。
  • [optional body] ,[optional footer] 如果还有需要补充或者详细展开的部分,我们可以在这两个部分说明。

自动化版本控制

有了规划化的提交后,我们就可以利用standard-version实现自动化版本控制与CHANGELOG自动生成了。

首先,我们全局安装一下standard-version

1
npm install -g standard-version

安装完成,可以查看一下版本,推荐一个团队最好使同一个大版本,避免一些奇怪的问题。

1
standard-version --version

当然,你也可以直接安装指定版本。

1
npm install -g [email protected]

有了规范的提交与standard-version 后,我们就可以愉快的进行版本控制和自动生成CHANGELOG了,只需要每次提交之后,在你的项目下面运行:

1
standard-version

即可。

我们很容易想到,standard-version可能会将git commit message, 自动整理生成CHANGELOG。 但版本升级怎么做到,规则是怎么样的呢?

这就取决于上面的git commit message中的type了。

  • 其中 fix对应于语义版本patch, 白话一点就是升级0.0.1个版本;
  • feat对应于与minor,也就是升级0.1.0个版本;

那么怎么实现从1.0.02.0.0呢,也就是改变major版本呢?

  • 其实只要在任何类型commit message后面的[optional body][optional footer]部分,以BREAKING CHANGE: 开头,写一些版本升级的内容即可,如:

    1
    2
    feat(xxx): 新增了xxx功能,实现了xxx 
    BREAKING CHANGE: xxxxxx

这里我们补充点语义版本控制的内容。

通常我们看到的版本是这样的:1.1.11.0.0-beta.11 或者 1.0.0-rc ,其实这种写法就是遵循语义化版本规范的,详细内容可以点上面链接查看,我们主要说明一下核心语法,即:

1
2
> <version core> ::= <major> "." <minor> "." <patch>
>

也就是版本 1.2.3,主版本号为1,次要版本为2,补丁号为3.

到这里你应该对规范化的git commit message有所了解,以及知道通过standard-version控制版本与自动生成CHANGELOG了。希望能对你有所帮助,养成良好的习惯,从而提高生产效率。