带你360度玩转项目工程化(二):实现规范化Git提交流程
目录：
带你360度玩转项目工程化(一):浅谈项目工程化
带你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
自动生成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))
集成gitflow+standard-verison插件使用
对于开发者来说，IDE就是我们的工作台，我们恨不得所有工作都能在IDE上面完成，因此将gitflow流程跟standard-verison集成到IDE的插件中，那么我们就能很方便的去完成全套规范化的git管理。
首先我这结合release分支管理流程：
本实践主要使用集成插件Git Flow Integration以及standrad version进行，具体源码已提交仓库https://gitee.com/gg9595/gitflow4idea.git
，后期再上传Idea仓库
Start Release
插件安装完成后release的操作主要在右下角菜单
填写分支名称：
Publish Release
点击右下角菜单发布分支
提交代码到分支
利用git commit messgae temeplate 规范提交内容如下
提交并且发布到远程仓库即可。
Finish Release
结束分支开发
.
点击完成后，会归并 release 分支到 'master’ 分支，用 release 分支名打 Tag，归并 release 分支到 ‘develop’，移除 release 分支。
Generate CHANGELOG
切换到master分支，还是右下角gitflow菜单点击选择”Generate CHANGELOG“
弹出以下信息，表示生成成功
打开CHANGELOG.md查看效果：
Push Tag
提交CHANGELOG.md到仓库并且提交Tag到远程仓库，push的时候选择push tag即可
结语
上面提及的所有工具插件最终目的就是为了敏捷，规范是一项工作的守则，但是我们都不希望规范成为一项我们需要花费大量时间和精力才能做到遵守的事情，作为开发者，创造使用工具，推动规范沉浸在我们的日常，是我们力所能及提高生产力的一件事情，我觉得挺好的。