关于前端:让你的-commit-更有价值

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

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

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 个字符。

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

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 type

This reverts commit ca16a365467e17915f0273392f4a13331b17617d.

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

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

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

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

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

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

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($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 available

Breaks $browser.onHashChange, which was removed (use onUrlChange instead)

fix($compile): couple of unit tests for IE9

Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.

Closes #392
Breaks foo.bar api, foo.baz should be used instead

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

首行就是简洁实用的要害信息，不便在 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 要不要写。其次，对人的标准大部分都是反兽性的，所以很可能在过不了多久，就会有同学慢慢的不依照标准来写。靠意志力来管制本人严格依照标准来写是须要额定消耗一些精力的，把精力消耗在这种事件下面切实有些节约。

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

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

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

// 全局装置 Commitizen
npm install -g commitizen

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

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

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

除此之外还有一种更举荐的形式，就是让你的仓库对 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 适配器。

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

npm install cz-customizable --save-dev

commitizen 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，外面中具体的正文。

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 文件，退出以下设置：

// 装置 husky
npm 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-cz
npm install commitlint-config-cz --save-dev


// commitlint.config.js 改为
module.exports = {
  extends: ['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 中能力失效。

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

// 装置 standard-verison
npm 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 敌对的话，能够在 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

关于前端:让你的-commit-更有价值

提交标准

commit messages 格局标准

Header

Type

Scope

Sbuject

Body

Footer

残缺的例子

例一: feat

例二: fix

例三: style

查看更多例子

标准 commit message 的益处

用工具实现标准提交

Commitizen

体验 git cz

Commitizen 敌对

cz-customizable 自定义中文配置

commitlint 校验提交

git commit 触发 git cz

生成 CHANGELOG

示例我的项目

扩大

更简单的自定义提醒

Commitizen 敌对徽章

参考文档

Just My Socks（注册教程内含优惠码）

关于前端:让你的-commit-更有价值

提交标准

commit messages 格局标准

Header

Type

Scope

Sbuject

Body

Footer

残缺的例子

例一: feat

例二: fix

例三: style

查看更多例子

标准 commit message 的益处

用工具实现标准提交

Commitizen

体验 git cz

Commitizen 敌对

cz-customizable 自定义中文配置

commitlint 校验提交

git commit 触发 git cz

生成 CHANGELOG

示例我的项目

扩大

更简单的自定义提醒

Commitizen 敌对徽章

参考文档

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）