2020年04月25日阅读 7

带你360度玩转项目工程化(二):实现规范化Git提交流程

如何实现规范化Git提交流程

一般来说，项目代码通过Git仓库进行管理，提交流程一般如下：

git pull --> git commit --> git push

由于大部分公司项目都是以项目组形式进行开发维护，基于GitFlow进行分支流程管理的前提下，虽然对版本进行了规范，但是从版本的管理维护的层面上，根据对项目成员每次提交的commit message进行分析，目前大部分的项目提交信息都是比较粗糙模糊，不知道这次提交具体是修复 bug 呢？还是增加新功能，还是单纯改了一些配置文件，亦或是重构了一些不好的代码。只能靠大家自己去猜测，就算是自己提交的信息，也可能因为时间长导致自己也不清楚具体这次提交是为了干什么，只能去提交记录里翻代码，长此以往，不利于产品的迭代，以及对于 bug 的定位。因此对commit message 规范化在项目的维护上是必须的。

具体git commit message 规范：

<type>(<scope>): <subject>

<BLANK LINE>

<body>

<BLANK LINE>

<footer>
复制代码

type(必需) ： Type of change：commit的类别；

scope(可选)：Scope of this change：此次commit的影响模块；

subject(必需)：Short description：简短的描述此次代码变更的主要内容

Header

1）type

type用于说明commit的类别，常用的标识如下：

标识名称	解释
feat	新功能（feature）
fix	修补bug
docs	文档（documentation）
style	格式（不影响代码运行的变动,空格,格式化,等等）
refactor	重构（即不是新增功能，也不是修改bug的代码变动
perf	性能 (提高代码性能的改变)
test	增加测试或者修改测试
build	影响构建系统或外部依赖项的更改(maven,gradle,npm 等等)
ci	对CI配置文件和脚本的更改
chore	对非 src 和 test 目录的修改
revert

（2）scope

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

（3）subject

subject是 commit 目的的简短描述，不超过50个字符，主要介绍此次代码变更的主要内容。

举个例子：

eg: feat(订单模块)：订单详情接口增加订单号字段

其中， feat对应type字段；订单模块对应scope(若果scope有内容，括号就存在)；“订单详情接口增加订单号字段”对应subject，简要说明此次代码变更的主要内容。

Body

Body 部分是对本次 commit 的详细描述，可以分成多行。

如：

（1）增加订单号字段；

（2）增加了订单退款接口；

日常项目开发中，如果Header中subject已经描述清楚此次代码变更的内容后，Body部分就可以为空。

Footer

（1）不兼容变动

（2）关闭 Issue

日常项目中开发，Footer不常用，可为空。

Revert

若需要撤销上一次的commit，header部分为：revert: 上一次commit的header内容；

body部分为：This reverts commit xxx，xxx是上一次commit对应的SHA 标识符。

Git commit message 插件介绍

写在纸上/文档上的规范不如让规范走进开发、贴近开发，利用开发工具去规范是开发者最容易接受、甚至是最欣然接受的方式，毕竟用得爽还没什么成本。

实现commit message 规范化的方式上，经过分析试用**，IDEA ”Git Commit Message“插件与VSCODE ”git-commit-plugin“ 插件**能够为规范化commit message提供良好的支持。

接下来以 IDEA ”Git Commit Message“插件使用进行体验介绍

1.commit 代码,弹出commit对话框

2.按照模板填写提交信息，点击OK

3.生成commit message

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-s3Lc3fqt-1587818803124)(C:\Users\lps\Documents\myblog\idea\git管理.assets\image-20200425180759192.png)\]

自动生成CHANGELOG.md

CHANGELOG.md是用于维护项目每个版本迭代升级的文件，Git版本管理并不仅仅是单向的Git代码提交，不断地commit，不断地迭代版本，还需要每个版本历史更新/解决的内容的维护，便于回溯与管理，而CHANGELOG.md的存在，是向团队开发者、项目管理者、需求等人员对项目每个版本具体更新内容清晰地了解，能追溯到版本commit对应的issue解决，便于找到对应责任chain。

例子如下：

项目开发者、项目管理者以及需求可以通过CHANGELOG.md查看每个版本改动的内容以及对应修复的bug。

怎么写 CHANGELOG.md？

由于大部分开发人员对写文档这些都有那么一丝丝的排斥，如下：

一个版本那么多issue,那么多commit，我很难办阿！

针对此状况，富强表示，CHANGELOG.md文件是可以根据我们经过规范化的commit message 生成的，生成后可以继续进行手动修改后，再提交。

使用standard-version自动生成CHANGELOG.md

standard-version 是一款遵循语义化版本（ semver）和 commit message 标准规范的版本和 changlog 自动化工具。通常情况下，我们在一个版本主要是release版本发布后我们会在 master 分支进行如下的版本发布操作：

git pull origin master
根据 pacakage.json 中的 version 更新版本号，更新 changelog
git add -A, 然后 git commit
git tag 打版本操作
push 版本 tag 和 master 分支到仓库

(1) 安装

本地输入以下命令进行全局安装

npm install -g standard-version
复制代码

(2) 使用

推荐用法：在package.json定义命令如下：

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

(3) 运行结果

在项目目录运行

npm run release 
复制代码

即可生成CHANGELOG(每次叠加)

生成例子：

 \# Change Log

 

All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.

 

<a name="1.0.4"></a>

\## 1.0.4 (2020-04-17)

  

<a name="1.0.3"></a>

\## 1.0.3 (2020-04-17)

 

\###  Features

 \* **lint:** 添加1功能 ([faee26d](http://url/commits/faee26d))

\* **lint:** 简化2配置 ([affeb7d](http://url/commits/affeb7d))
复制代码