一、为什么需要制定提交规范？
在团队协作开发时，每个人提交代码时都会写 commit message。
每个人都有自己的书写风格，可以说是五花八门，十分不利于阅读和维护。
一般来说，大厂都有一套的自己的提交规范，尤其是在一些大型开源项目中，commit message 都是十分一致的。
因此，我们需要制定统一标准，促使团队形成一致的代码提交风格，更好的提高工作效率，成为一名有追求的工程师。
二、采用哪种规范？
采用Angular的git commit 规范，基本项目都在采用这套规范。
三、有哪些知名开源项目在用这个规范？
1.Angular项目
项目github地址：
https://github.com/angular/angular
2.Vue项目
项目github地址：
等等…
四、规范具体介绍
Commit Message 格式:每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。
<type>(<scope>): <subject>
<空行>
<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。
3040
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
