Git 提交信息规范

一、为什么需要制定提交规范？

在团队协作开发时，每个人提交代码时都会写 commit message。

每个人都有自己的书写风格，可以说是五花八门，十分不利于阅读和维护。

一般来说，大厂都有一套的自己的提交规范，尤其是在一些大型开源项目中，commit message 都是十分一致的。

因此，我们需要制定统一标准，促使团队形成一致的代码提交风格，更好的提高工作效率，成为一名有追求的工程师。

二、采用哪种规范？

采用Angular的git commit 规范，基本项目都在采用这套规范。

三、有哪些知名开源项目在用这个规范？

1.Angular项目

项目github地址：

https://github.com/angular/angular

2.Vue项目

项目github地址：

https://github.com/vuejs/vue

等等…

四、规范具体介绍

Commit Message 格式:每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。

(): <空行><空行>

其中，Header 是必需的，Body 和 Footer 可以省略。

Header :

Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。

1.type

feat：新增功能；fix：修复bug；docs：修改文档；refactor：代码重构，未新增任何功能和修复任何bug；build：改变构建流程，新增依赖库、工具等（例如webpack修改）；style：仅仅修改了空格、缩进等，不改变代码逻辑；perf：改善性能和体现的修改；chore：非src和test的修改；test：测试用例的修改；ci：自动化流程配置修改；revert：回滚到上一个版本；
 

2.scope

用于说明 commit 影响的范围，比如数据层、控制层、视图层、包名、文件名等等。

3.subject

是 commit 目的的简短描述，不超过50个字符，结尾不加句号。

Body :

Body 部分是对本次 commit 的详细描述,应该说明代码变动的动机，以及与以前行为的对比。

Footer :

Footer有两种情况

1.是否有重大的改变(是否有突破性的变化)

框架式改变，或者跟上一版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。

2.这一变化是否影响到任何尚未解决的问题(关闭issue)

可以填写fix #1 等于关闭问题1 或者 使用Closes #1,关闭多个issue使用fix #1,#2,#3 逗号分割，关闭了三个issue。

五、用工具(框架)帮助我们实现这个规范

如果手动去实现这个规范，每次提交信息都要排好版，格式化，那将是一件灾难性的事件。

所以我们采用能帮我们实现这个规范的工具(框架):

commitizen

github地址：https://github.com/commitizen/cz-cli

全局性安装此工具(框架):

npm install commitizen -g
 

然后，在项目目录里，运行下面的命令，使其支持 Angular 的 Commit message 格式(如果项目里面已经存在无需执行此命令):

commitizen init cz-conventional-changelog --save --save-exact
 

之前使用git commit提交信息，现在使用git cz命令

选择一个type，进入下一步填写信息

填写完毕后提示是否有突破性的改变的说明

为了测试，选择y

进入下一步提示是否有对issue进行解决

如果这次commit有对提出的issue进行修复，选择y，然后填写 fix #1 比如 关闭问题1 仓库那边会自动关闭这个issue。