为什么要对git commit信息进行规范化
Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交。但是，一般来说，commit message 应该清晰明了，说明本次提交的目的。但是每个人的做事风格不一，很有可能提交的说明让人看不懂，举个极端的例子，如下图：
所以，最好能有一个规范进行约束，这样能够降低团队间的沟通成本，让提交日志简单易懂，团队外的人员也更容易看懂！
规范化git commit 信息的作用
- 提供更多的历史信息，方便快速浏览。
- 可以过滤某些commit（比如文档改动），便于快速查找信息
- 可以直接从commit生成Change log。
- 可读性好，清晰，不必深入看代码即可了解当前commit的作用。
- 为 Code Reviewing做准备
- 方便跟踪工程历史
- 让其他的开发者在运行 git blame 的时候想跪谢
- 提高项目的整体质量，提高个人工程素质
git commit规范化工具git Commitizen的使用
安装
全局安装commitizen
npm install -g commitizen
在项目中使用
- 首先需要在项目中初始化commitizen，切换到项目的根目录下，让后执行如下命令：
commitizen init cz-conventional-changelog --save --save-exact
- 提交代码时使用，需要执行命令
git add .
git cz //不在需要执行git commit，全部改为git cz
此时会出现提示，按提示一步步输入commit信息，完成后即为格式化后的commit信息
git commitizen的格式化结构
每次提交，Commit message 都包括三个部分：header，body 和 footer。
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
其中，header 是必需的，body 和 footer 可以省略。不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。
-
Header
Header 部分只有一行，包括三个字段：type（类型，必需）、scope（影像范围，可选）和subject（简略信息，必需）。
-
type
用于说明 commit 的类别，只允许使用下面11个标识。
- feat：功能
- fix：修复bug
- docs：只改动了文档相关的内容
- style：不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
- refactor：代码重构
- perf：提高性能的改动
- test：添加测试或者修改现有测试
- build：构造工具的或者外部依赖的改动，例如webpack，npm
- ci：与CI（持续集成服务）有关的改动
- chore：其它杂项修改，例如构建过程或辅助工具的变动
- revert：执行git revert打印的message
-
Scope
用来说明本次Commit影响的范围，即简要说明修改会涉及的部分，这个是选填项。
-
Subject
用来简要描述本次改动，要精简概述，后面在Body里还可以给出具体信息。并且最好遵循下面两条:
- 以动词开头，使用第一人称现在时，比如change（更改），而不是changed（更改了）或changes
- 结尾不用句号
-
-
body
本次改动的详细描述
-
footer
脚注部分，此部分一般只用于以下两种情况：
-
不兼容变动
如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。
BREAKING CHANGE: isolate scope bindings definition has changed. To migrate the code follow the example below: Before: scope: { myAttr: 'attribute', } After: scope: { myAttr: '@', } The removed `inject` wasn't generaly useful for directives so there should be no code using it. -
关闭Issue
如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。
Closes #234
-
