git原理--commit规范

一直是 ESLint 的忠实用户，深知规范的重要性。然而，在新项目交接中，我被 Git Commit 规范逼疯了。才意识到本身的疏忽，因而便有了一探究竟的想法。
关键词：husky+@commitlint/cli ghooks+validate-commit-msg

原文连接 http://jartto.wang/2018/07/08/git-commit/。

1、为何须要规范？

无规矩不成方圆，编程也同样。

若是你有一个项目，从始至终都是本身写，那么你想怎么写均可以，没有人能够干预你。但是若是在团队协做中，你们都张扬个性，那么代码将会是一团糟，好好的项目就被糟践了。不论是开发仍是往后维护，都将是灾难。

这时候，有人提出了何不统一标准，你们都按照这个标准来。因而 ESLint，JSHint 等代码工具如雨后春笋般涌现，成为了项目构建的必备良品。

Git Commit 规范可能并无那么夸张，但若是你在版本回退的时候看到一大段糟心的 Commit，恐怕会懊恼不已吧。因此，严格遵照规范，利人利己。

2、具体规则

先来看看公式：

<type>(<scope>): <subject>

type

用于说明 commit 的类别，只容许使用下面8个标识。

1. feat：新功能（feature）
2. fix：修补bug
3. docs：文档（documentation）
4. style： 格式（不影响代码运行的变更）
5. refactor：重构（即不是新增功能，也不是修改bug的代码变更）
6. test：增长测试
7. chore：构建过程或辅助工具的变更
8. build: 本地creator构建

scope

用于说明 commit 影响的范围，好比数据层、控制层、视图层等等，视项目不一样而不一样。

subject

是 commit 目的的简短描述，不超过50个字符。

1.以动词开头，使用第一人称如今时，好比change，而不是changed或changes

2.第一个字母小写

3.结尾不加句号（.）

规范参考自阮一峰老师的文章：Commit message 和 Change log 编写指南。

3、异常处理

咱们先来看看这个异常提醒：

INVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" !

jartto:fix bug

这里之因此报出这个警告，是由于个人提交出现了两个问题：

其一，使用了规范外的关键字；

其二，很细节的问题，jartto：后少了空格；

这时候我才回忆起来，当时提交一直失败，情急之下直接强制提交，因此之后的提交都会抱出这个异常。大体意思就是：

你的以前的 Commit 不合格～你的以前的 Commit 不合格～你的以前的 Commit 不合格

这时候就很烦了，咱们只能去将以前的错误修正，那么如何操做呢？

4、如何修改以前的 commit 信息？

其实并不复杂，咱们只须要这样作:

1. 将当前分支无关的工做状态进行暂存

git stash

1. 将 HEAD 移动到须要修改的 commit 上

git rebase 9633cf0919^ --interactive

1. 找到须要修改的 commit ,将首行的 pick 改为 edit
2. 开始着手解决你的 bug
3. git add 将改动文件添加到暂存
4. git commit –amend 追加改动到提交
5. git rebase –continue 移动 HEAD 回最新的 commit
6. 恢复以前的工做状态

git stash pop

大功告成，是否是想把整个 Commit 都修改一遍，逃～

此处参考自：修改 Commit 日志和内容

5、项目中使用

这时候问题又来了，为何我提交的时候会有警告，这个又是如何作到的呢？

这时候，咱们须要一款 Node 插件 validate-commit-msg 来检查项目中 Commit message 是否规范。

1.首先，安装插件：

npm install --save-dev validate-commit-msg

2.使用方式一，创建 .vcmrc 文件：

{

  "types": ["feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert"],

  "scope": {

    "required": false,

    "allowed": ["*"],

    "validate": false,

    "multiple": false

  },

  "warnOnFail": false,

  "maxSubjectLength": 100,

  "subjectPattern": ".+",

  "subjectPatternErrorMsg": "subject does not match subject pattern!",

  "helpMessage": "",

  "autoFix": false

}

3.使用方式二：写入 package.json

{

  "config": {

    "validate-commit-msg": {

      /* your config here */

    }

  }

}

4.但是咱们若是想自动使用 ghooks 钩子函数呢？

{

  …

  "config": {

    "ghooks": {

      "pre-commit": "gulp lint",

      "commit-msg": "validate-commit-msg",

      "pre-push": "make test",

      "post-merge": "npm install",

      "post-rewrite": "npm install",

      …

    }

  }

  …

}

在 ghooks 中咱们能够作不少事情，固然不仅是 validate-commit-msg 哦。

更多细节请参考：validate-commit-msg

6、Commit 规范的做用

1. 提供更多的信息，方便排查与回退；
2. 过滤关键字，迅速定位；
3. 方便生成文档；

7、生成 Change log

正如上文提到的生成文档，若是咱们的提交都按照规范的话，那就很简单了。生成的文档包括如下三个部分：

New features

Bug fixes

Breaking changes.

每一个部分都会罗列相关的 commit ，而且有指向这些 commit 的连接。固然，生成的文档容许手动修改，因此发布前，你还能够添加其余内容。

这里须要使用工具 Conventional Changelog 生成 Change log ：

npm install -g conventional-changelog

cd jartto-domo

conventional-changelog -p angular -i CHANGELOG.md -w

为了方便使用，能够将其写入 package.json 的 scripts 字段。

{

  "scripts": {

    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0"

  }

}

这样，使用起来就很简单了：

npm run changelog

到这里，咱们全部的问题都搞明白了，Cheers～

8、总结

看完文章，你还会如此放荡不羁吗？你还会为所欲为的编写 Commit 吗？你还会如此 git commit -m "hello jartto"提交吗？

答案是否认的，由于使用了钩子函数，你没有机会了，不然将是无穷无尽的恢复 Commit。这倒能够养成良好的提交习惯，～

注意

在设置完git hooks以后 有使用sourceTree的同窗，可能会出现报错；

这个报错出现的缘由是由于 在sourceTree中的环境变量node找不到！sourceTree执行hooks文件和直接用命令行稍有不一样不一样。

打开 ./.git/hooks/ 能够发现有不少hook文件，文件的头部都有node环境标识 ---- #!/usr/bin/env node

报错的根本缘由是 该标识的node 获取不到

修改方法：

• 查看本机的node路径

$ which node

# 个人路径是 #!/usr/local/bin/node

将正确的node路径放在 hooks下文件的头部 做为声明便可；

• 本身修改hooks文件比较麻烦，伙伴直接难以同步
• 修改以后 sourceTree功能大多能使用 可是commit依然没法正常使用
• 使用husky

使用husky+@commitlint/cli

husky和ghooks 都能实现对git中的hooks进行控制（在每一步git操做中增长钩子），如图所示

主要区别是文件头的声明方式不同：

ghooks 不兼容sourceTree

#!/usr/bin/env node

# ghooks

#!/bin/sh

# husky

安装依赖：

npm i -D husyk @commitlint/cli

新建.commitlintrc.js 文件

module.exports = {

parserPreset: 'conventional-changelog-conventionalcommits',

rules: {

'body-leading-blank': [1, 'always'],

'footer-leading-blank': [1, 'always'],

'header-max-length': [2, 'always', 72],

'scope-case': [2, 'always', 'lower-case'],

'subject-case': [

2,

'never',

['sentence-case', 'start-case', 'pascal-case', 'upper-case']

],

'subject-empty': [2, 'never'],

'subject-full-stop': [2, 'never', '.'],

'type-case': [2, 'always', 'lower-case'],

'type-empty': [2, 'never'],

'type-enum': [

2,

'always',

[

'build',

'chore',

'docs',

'feat',

'fix',

'refactor',

'style',

'test'

]

]

}

};

配置package.json

"husky": {

"hooks": {

"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"

}

}

验证commit

git commit -m 'aaa'

husky > commit-msg (node v8.11.3)

⧗  input: aaa

✖  subject may not be empty [subject-empty]

✖  type may not be empty [type-empty]

✖  found 2 problems, 0 warnings

ⓘ  Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

husky > commit-msg hook failed (add --no-verify to bypass)

git commit -m 'feat: 验证commitlint'

husky > commit-msg (node v8.11.3)

[test 1b4a515] feat: 验证commitlint

1 file changed, 1 insertion(+), 1 deletion(-)

文章首发于 Jartto's blog ， 原文连接 http://jartto.wang/2018/07/08...。![!