一个继续更新的github笔记，链接地址：Front-End-Basics，本文地址：让你的 commit 更有价值。

提交标准

AngularJS 在开发者文档中对于 git commit 的领导阐明，提到严格的 git commit 格局标准能够在浏览我的项目历史的过程中看到更易读的信息，并且能用 git commit 的信息间接生成 AngularJS 的 change log 。

commit messages 格局标准

commit messages 由 header 、body 、footer 组成。

header 又蕴含 type 、scope 、subject 。header 是必须的，不过其中的 scope 是可选的。

body 和 footer 能够省略。

<type>(<scope>): <subject>// 空行<BLANK LINE><body>// 空行<BLANK LINE><footer>
注：为了能在 github 以及各种 git 工具中看得更清晰，commit messages 的每一行都不要超过 100 个字符。

Header

Type

类型必须是以下几种之一：

  • feat: 新性能
  • fix: bug 修复
  • docs: 仅批改文档
  • style: 批改格局（空格，格式化，省略分号等），对代码运行没有影响
  • refactor: 重构（既不是修 bug ，也不是加性能）
  • build: 构建流程、内部依赖变更，比方降级 npm 包、批改 webpack 配置等
  • perf: 性能优化
  • test: 测试相干
  • chore: 对构建过程或辅助工具和库（如文档生成）的更改
  • ci: ci 相干的更改

除此之外，还有一个非凡的类型 revert ，如果以后提交是为了撤销之前的某次提交，应该用 revert 结尾，前面加上被撤销的提交的 header，在 body 中应该注明： This reverts commit <hash>. ，hash 指的就是将要被撤销的 commit SHA 。

// 例如revert: feat(user): add user typeThis reverts commit ca16a365467e17915f0273392f4a13331b17617d.

Scope

scope 能够指定提交更改的影响范畴，这个视我的项目而定，当批改影响超过单个的 scope 时，能够指定为 * 。

Sbuject

subject 是指更改的简洁形容，长度约定在 50 个字符以内，通常遵循以下几个标准：

  • 用动词结尾，第一人称当初时表述，例如：change 代替 changed 或 changes
  • 第一个字母小写
  • 结尾不加句号（.）

Body

body 局部是对本地 commit 的详细描述，能够分成多行。

跟 subject 相似，用动词结尾，第一人称当初时表述，例如：change 代替 changed 或 changes。

body 应该阐明批改的起因和更改前后的行为比照。

Footer

footer 根本用在这两种状况：

  • 不兼容的改变（ Breaking Changes ）,通常用 BREAKING CHANGE: 结尾，前面跟一个空格或两个换行符。残余的局部就是用来阐明这个变动的信息和迁徙办法等。
  • 敞开 Issue, github 敞开 Issue 的例子
// BREAKING CHANGE: 的例子BREAKING CHANGE: isolate scope bindings definition has changed and    the inject option for the directive controller injection was removed.    To migrate the code follow the example below:    Before:    scope: {      myAttr: 'attribute',      myBind: 'bind',      myExpression: 'expression',      myEval: 'evaluate',      myAccessor: 'accessor'    }    After:    scope: {      myAttr: '@',      myBind: '@',      myExpression: '&',      // myEval - usually not useful, but in cases where the expression is assignable, you can use '='      myAccessor: '=' // in directive's template change myAccessor() to myAccessor    }    The removed `inject` wasn't generaly useful for directives so there should be no code using it.// Closes Issue 例子Closes #2314, #3421

残缺的例子

例一: feat

feat($browser): onUrlChange event (popstate/hashchange/polling)Added new event to $browser:- forward popstate event if available- forward hashchange event if popstate not available- do polling when neither popstate nor hashchange availableBreaks $browser.onHashChange, which was removed (use onUrlChange instead)

例二: fix

fix($compile): couple of unit tests for IE9Older IEs serialize html uppercased, but IE9 does not...Would be better to expect case insensitive, unfortunately jasmine doesnot allow to user regexps for throw expectations.Closes #392Breaks foo.bar api, foo.baz should be used instead

例三: style

style($location): add couple of missing semi colons

查看更多例子

标准 commit message 的益处

  • 首行就是简洁实用的要害信息，不便在 git history 中疾速浏览
  • 具备详实的 body 和 footer ，能够清晰的看出某次提交的目标和影响
  • 能够通过 type 过滤出想要查找的信息，也能够通过关键字疾速查找相干提交
  • 能够间接从 commit 生成 change log
// 列举几个罕用的 log 参数// 输入 log 的首行git log --pretty=oneline// 只输入首行的 commit 信息。不蕴含 hash 和 合并信息等git log --pretty=format:%s// 查找无关“更新菜单配置项”的提交git log --grep="更新菜单配置项"// 打印出 chenfangxu 的提交git log --author=chenfangxu// 红色的短 hash，黄色的 ref , 绿色的绝对工夫git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset'

用工具实现标准提交

下面介绍了标准提交的格局，如果让各位同学在 git commit 的时候严格依照下面的标准来写，首先心智是有累赘的，得记住不同的类型到底是用来定义什么的，subject 怎么写，body 怎么写，footer 要不要写。其次，对人的标准大部分都是反兽性的，所以很可能在过不了多久，就会有同学慢慢的不依照标准来写。靠意志力来管制本人严格依照标准来写是须要额定消耗一些精力的，把精力消耗在这种事件下面切实有些节约。

用工具实现标准提交的计划，一种是在提交的时候就提醒必填字段，另一种是在提交后校验字段是否符合规范。这两种在理论我的项目中都是很有必要的。

Commitizen

Zen-like commit messages for internet citizens. 嗯~~一种禅意

Commitizen 是一个帮忙撰写标准 commit message 的工具。他有一个命令行工具 cz-cli，接下来会把应用 Commitizen 分成几个阶段来介绍。

体验 git cz

// 全局装置 Commitizennpm install -g commitizen

你的仓库可能还不是对 Commitizen 敌对的，此时运行 git cz 的成果跟 git commit 一样，也就是没有成果。 不过，能够执行 npx git-cz 来体验。

如果想间接运行 git cz 实现语义化的提交，能够依据 streamich/git-cz 文档中说的全局装置 git cz。

// 全局装置 git cznpm install -g git-cz

除此之外还有一种更举荐的形式，就是让你的仓库对 Commitizen 敌对。

Commitizen 敌对

全局装置 Commitizen 后，用 cz-conventional-changelog 适配器来初始化你的我的项目

// 初始化 cz-conventional-changelog 适配器commitizen init cz-conventional-changelog --save-dev --save-exact

下面的初始化做了三件事：

  • 装置 cz-conventional-changelog 依赖
  • 把依赖保留到 package.json 的 dependencies 或 devDependencies 中
  • 在根目录的 package.json 中 增加如下所示的 config.commitizen
"config": {    "commitizen": {      "path": "./node_modules/cz-conventional-changelog"    }  }

或者，在我的项目根目录下新建一个 .czrc 文件，内容设置为

{  "path": "cz-conventional-changelog"}

当初运行 git cz 成果如下：

cz-customizable 自定义中文配置

通过下面的截图能够看到，提交的配置选项都是英文的，如果想改成中文的，能够应用 cz-customizable 适配器。

运行上面的命令，留神之前曾经初始化过一次了，这次再初始化，须要加 --force 笼罩

npm install cz-customizable --save-devcommitizen init cz-customizable --save-dev --save-exact --force

当初 package.json 中 config.commitizen 字段为：

"config": {    "commitizen": {      "path": "./node_modules/cz-customizable"    }  }

cz-customizable 文档中阐明了查找配置文件的形式有三种，咱们依照第一种，在我的项目根目录创立一个 .cz-config.js 的文件。依照给出的示例 cz-config-EXAMPLE.js 编写咱们的 config。 commit-type 能够参考 conventional-commit-types 。

能够点击查看我配置好的文件 qiqihaobenben/commitizen-git/.cz-config.js ，外面中具体的正文。

commitlint 校验提交

Commitizen 文档中开始就介绍到，Commitizen 能够在触发 git commit 钩子之前就能给出提醒，然而也明确示意提交时对 commit messages 的校验也是很有用的。毕竟即应用了 Commitzen，也是能绕过去，所以提交最初的校验很重要。

commitlint 能够查看 commit messages 是否合乎惯例提交格局，须要一份校验配置，举荐 @commitlint/config-conventional 。

npm i --save-dev @commitlint/config-conventional @commitlint/cli

在我的项目根目录创立 commitlint.config.js 文件并设置校验规定：

module.exports = {  extends: ["@commitlint/config-conventional"],  // rules 外面能够设置一些自定义的校验规定  rules: {},};

在我的项目中装置 husky ，并在我的项目根目录新建 husky.config.js 文件，退出以下设置：

// 装置 huskynpm install --save-dev husky// husky.config.js 中退出以下代码module.exports = {  "hooks": {    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"  }}
留神：因为 @commitlint/config-conventional 校验规定遵循 Angular 的标准， 所以咱们在用 cz-customizable 自定义中文配置时， 是依照给出的合乎 Angular 标准的示例 cz-config-EXAMPLE.js 编写.cz-config.js 的。然而如果你自定义的 Commitizen 配置不合乎 Angular 标准，能够应用 commitlint-config-cz 设置校验规定。（举荐还是依照 Angular 标准进行 cz-customizable 自定义配置）
// 装置 commitlint-config-cznpm install commitlint-config-cz --save-dev// commitlint.config.js 改为module.exports = {  extends: [    'cz'  ]};

git commit 触发 git cz

在提交的时候，咱们都习惯了 git commit ，尽管换成 git cz 不难，然而如果让开发者在 git commit 时无感知的触发 git cz 必定是更好的，
而且也能防止不相熟我的项目的人间接 git commit 提交一些不符合规范的信息。

咱们能够在 husky.config.js 中设置：

"hooks": {  "prepare-commit-msg": "exec < /dev/tty && git cz --hook || true",}
留神： 在 window 零碎，可能须要在 git base 中能力失效。

生成 CHANGELOG

standard-version
是一个应用 semver 和 conventional-commits 反对生成 CHANGELOG 进行版本控制的实用程序。
standard-version 不只是能生成 CHANGELOG , 还能依据 commit 的 type 来进行版本控制。

// 装置 standard-verisonnpm i --save-dev standard-version// 在 package.json 中的 scripts 退出 standard-version{  "scripts": {    "release": "standard-version"  }}

示例我的项目

能够查看 commitizen-git ，外面演绎了疾速配置 Commitizen 敌对仓库的步骤。
差不多三五分钟就能搞定。

能够看一下配置完后，执行 git commit 的成果。

扩大

更简单的自定义提醒

cz-customizable 中自定义配置项通常状况是够用的，
commitlint 中校验的规定基本上也是够用的，然而会有比拟硬核的开发者会感觉还是不够，还要更多。比方一些 prompt 更加自定义，
提交时询问的 question 增加更多的逻辑，比方能够把一些重要的字段校验提前到 Commitizen 中，或者增加更多自定义的校验。

如果真想这么干，那就去 fork 一份 cz-conventional-changelog 或者 cz-customizable 来改，
或者间接本人写一个 adapter。

Commitizen 敌对徽章

如果把仓库配置成了对 Commitizen 敌对的话，能够在 README.md 中加上这个小徽章：

参考文档

  • AngularJS Git Commit Message Conventions
  • conventional commit format
  • Commit message 和 Change log 编写指南
  • Writing Git commit messages
  • A Note About Git Commit Messages（文中讲了 subject 50 个字符的约定怎么来的）
  • 个性化你的 Git Log 的输入格局
  • git pretty formats