规范 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格式如下：

<type>[optional scope]: <description>

[optional body]

[optional footer]

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

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。

npm install -g standard-version

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

standard-version --version

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

npm install -g standard-version@7.1.0

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

standard-version

即可。

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

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

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

那么怎么实现从1.0.0 到2.0.0呢，也就是改变major版本呢？

其实只要在任何类型commit message后面的[optional body]或[optional footer]部分，以**BREAKING CHANGE: ** 开头，写一些版本升级的内容即可，如：
```
feat(xxx): 新增了xxx功能，实现了xxx 
BREAKING CHANGE: xxxxxx
```

这里我们补充点语义版本控制的内容。
通常我们看到的版本是这样的：1.1.1 、1.0.0-beta.11 或者 1.0.0-rc ，其实这种写法就是遵循语义化版本规范的，详细内容可以点上面链接查看，我们主要说明一下核心语法，即：
<version core> ::= <major> "." <minor> "." <patch>
也就是版本 1.2.3，主版本号为1，次要版本为2，补丁号为3.

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

规范#

自动化版本控制#

规范

自动化版本控制