为什么须要制订提交标准

为什么须要制订提交标准，简略总结如下：

  • 让之后的我的项目维护者理解代码呈现特定变动和增加feature的起因
  • 不便code review
  • 清晰的历史记录，不便疾速浏览查找，回溯之前的工作内容
  • 标准的提交记录可用于主动生成版本公布日志(CHANGELOG.MD)
  • 基于提交类型，触发构建和部署流程

怎么制订提交标准

Conventional Commits是目前应用最宽泛的提交信息标准，其次要受 AngularJS标准 的启发

commit 格局如下：

<type>[scope]: <subject>//空一行[optional body]//空一行[optional footer(s)]

标准阐明

# 次要typefeat: 减少新性能fix: 修复bug# 非凡typedocs: 只改变了文档相干的内容style: 代码格式化相干的改变，例如去掉空格、扭转缩进、增删分号，不扭转代码逻辑refactor: 代码重构时应用，没有增加新性能或者修复bugperf: 进步性能的改变chore: 结构工具的改变，扭转构建流程、减少依赖库、工具等，例如webpack，npm# 暂不应用typetest: 增加测试用例或者批改现有测试用例revert: 回退，撤销上一次的 commitci: 与CI（继续集成服务）无关的改变

如何束缚标准

怎么确保每个提交都能符合规范呢，最好的形式就是通过工具来生成和校验；

  • commitizen是一个nodejs命令行工具，通过交互的形式，生成符合规范的git commit；
  • conventional-changelog是一款能够依据我的项目的commit 和 metadata信息主动生成 changelogs 和 release notes的系列工具；
  • standard-version能够主动帮你实现生成version、打tag, 生成CHANGELOG等系列过程；

commitizen

是一个撰写合格 Commit message 的工具。

格局校验commitlint

应用commitlint和husky来进行提交查看，当执行git commit时会在对应的git钩子上做校验，只有合乎格局的Commit message能力提交胜利。

生成Change log 的工具

conventional-changelog

主动版本治理和生成CHANGELOG

standard-version一个用于生成CHANGELOG.md和进行SemVer(语义化版本号)发版的命令行工具，次要性能：

  • 主动批改最新版本号，能够是package.json或者自定义一个文件
  • 读取最新版本号，创立一个最新的git tag
  • 依据提交信息，生成CHANGELOG.md
  • 创立一个新提交包含 CHANGELOG.md和package.json

参考

标准GIT代码提交信息&自动化版本治理
Commit message 和 Change log 编写指南