前言

大学时候就用git管理自己的代码，无论是分支还是工作流都会有规范，唯独到git-commit的message就随心所欲了，没有找到章法。还有以前一直都是自己手写CHANGELOG.md，每次都是自己一点点地编写，可是当开发完到要写CHANGELOG.md的时候就忘记之前自己都做了什么改动了，还得一点点翻看之前的commit记录，然而自己的提交记录简直惨不忍睹，都看不出自己修改了什么东西。

规范git提交信息的好处:

  1. 自动生成CHANGELOGs;
  2. 自动生成语义化的版本号;
  3. 更容易和你的团队，和公众，以及利益相关者沟通项目的变化;
  4. 触发构建和发布的进程;
  5. 更容易让其他人为项目贡献代码，因为规范的提交允许他们能知道更加结构化的提交历史;

Ref: Why Use Conventional Commits

最近友人推荐了一套规范化提交的工具链给我: commitizen => commitlint => standard-version，尝试了一下，还不错推荐给大家。

commitizen

commitizen是git提交信息框架，相当于生成一个模板，你照着填写提交信息就可以了，commitizen可以指定不同的Adapter以满足不同的提交规范。

cz-conventional-changelog是commitizen指定的一个Adapter，符合AngularJS团队提交规范。

如果不想用AngularJS规范，想自定义规范，可以用cz-customizableAdapter来自定义规范，把cz-conventional-changelog换成cz-customizable，本文就不展开了。

个人推荐npm全局安装，反正每个git管理的项目提交的时候都受用

npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc

commitlint

commitlint可以帮助我们校验commit messages是否符合规范，不符合的直接拒绝提交。

一般是项目捆绑以防止项目开发成员出现不规范的提交信息，所以这个commitlint一般都会是团队的要求，在开发者本地校验一次，以及在CI集成部署的时候校验一次会是一种比较好的做法。

而个人而言，如果你习惯每次提交都走commitizen，就没有必要安装这个commitlint，因为你的提交肯定是合乎规范的。

开发者本地在安装commitlint之后还可以npm装个husky绑定到git-hook上，每次git-commit就触发git-hook执行commitlint检查，就不用每次都手动执行commitlint，只管commit就好了

安装和使用commitlint和husky本文就不多阐述了，根据下面的Ref官方教程实践即可。

Ref: commitlint guides local setup

standard-version

standard-version能为有了上面规范提交的项目自动生成CHANGELOG和语义化的版本号

和commitizen一样推荐全局安装，毕竟全部项目都是走standard-version

npm install -g standard-version

standard-version # 生成或者更新CHANGELOG.md并打上符合语义化版本号的git-tag
git push --follow-tags origin master && npm publish # 或者docker push, gem push, 等等

简述语义化版本

版本号格式：X.Y.Z (主版本号.次版本号.修订号):

  1. 进行不向下兼容的修改时，递增主版本号;
  2. API 保持向下兼容的新增及修改时，递增次版本号;
  3. 修复问题但不影响API 时，递增修订号;

Ref: 语义化版本 2.0.0

参考

优雅的提交你的 Git Commit Message
Angular 团队的规范
Conventional Commits specification