git-hooks

Git hooks

Git 钩子

和其它版本控制系统一样，Git 能在特定的重要动作发生时触发自定义脚本。

git hook	执行时机	用法	说明
pre-commit	git commit 执行前	来检查代码风格是否一致	可以使用 git commit --no verify 命令绕过该钩子
commit-msg	git commit 执行前	用来在提交通过前验证项目状态或提交信息	可以使用 git commit --no verify 命令绕过该钩子

Husky

一个可以高效管理 Git hooks 的工具

使用 huskey

首先进行安装 npm install husky --save-dev
package.json 配置 script 脚本 { "prepare": "husky install" }
执行命令 npm run prepare 进行 husky 初始化，执行完成后会生成一个 .husky 文件夹
管理钩子，创建命令 npx husky add .husky/pre-commit
执行完后会在 .husky 下生成一个 pre-commit 文件夹，修改文件内容
```
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npm run link
```
git commit 命令时会先执行 pre-commit 这个脚本，也就是执行 npm run link
重复上述命令生成其他钩子脚本

lint-staged

对提交的代码进行检查的工具

安装与使用

安装 npm install --save-dev lint-staged
设置 pre-commit 钩子来运行 lint-staged
安装代码检查工具（ ESLint ）和格式化工具( Prettier )
配置 lint-staged 来运行代码检测与格式化
可以在 package.json 中配置，也可以新建文件 .lintstagedrc 进行配置

{
  "lint-staged": {
    "src/**/*.{js,jsx,ts,tsx,json}": [
      "prettier --write",
      "eslint"
    ]
  }
}

Prettier

一款代码格式化工具

安装与使用

安装 npm install --save-dev --save-exact prettier
创建配置文件 .prettierrc.json
创建忽略文件配置 .prettierignore
格式化命令 npx prettier --write .
如果与 ESLint 一起使用，需要安装 eslint-config-prettier 来屏蔽一些冲突的配置，它关闭了所有不必要的或可能与Prettier冲突的ESLint规则

ESLint

javascript 代码检测工具

安装与使用

安装 npm install eslint --save-dev
添加配置文件 npx eslint --init 也可以手动添加 .eslintrc.js
运行检测 eslint yourfile.js

配置

具体配置规则可以参考官方网站

module.exports = {
    "env":{ "es6": true },
    "extends": ["eslint:recommended"],
    "parserOptions": {
        "ecmaVersion": 6,
        "ecmaFeatures": {
            "jsx": true
        }
    },
    "rules": {
        "no-unused-vars": [2, { "vars": "local", "args": "after-used" }]
    }
}

commitlint

一款校验提交信息的工具

安装与使用

安装 npm install @commitlint/cli @commitlint/config-conventional -D
创建文件配置 commitlint.config.js, 并编辑内容为： module.exports = {extends: ['@commitlint/config-conventional']}
添加钩子脚本 npx husky add .husky/commit-msg, 并编辑运行脚本为： npx commitlint --edit

具体配置

module.exports = {
  extends: ["@commitlint/config-conventional"],
  rules: {
    "scope-empty": [2, 'never'],
    "type-enum": [2, 'always', ['feat', 'fix', 'perf', 'refactor', 'docs', 'style', 'test', 'build', 'revert', 'ci', 'chore', 'release']]
  }
};

commit

git 在每次提交时，都需要填写 commit message。

git commit -m 'this is a test'

commit message 就是对你这次的代码提交进行一个简单的说明，好的提交说明可以让人一眼就明白这次代码提交做了什么。

既然明白了 commit message 的重要性，那我们就更要好好的学习一下 commit message 规范。下面让我们看一下 commit message 的格式：

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

我们可以发现，commit message 分为三个部分(使用空行分割):

提交类型（type）: 必填, 描述修改的类型，例如：feat，fix
影响范围（scope）：必填，描述修改的影响范围
标题行（subject）: 必填, 描述主要修改类型和内容。
主题内容（body）: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等。
页脚注释（footer）: 可以写注释，放 BUG 号的链接。

type

commit 的类型：

feat: 新功能、新特性
fix: 修改 bug
perf: 更改代码，以提高性能（在不影响代码内部行为的前提下，对程序性能进行优化）
refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
docs: 文档修改
style: 代码格式修改, 注意不是 css 修改（例如分号修改）
test: 测试用例新增、修改
build: 影响项目构建或依赖项修改
revert: 恢复上一次提交
ci: 持续集成相关文件修改
chore: 其他修改（不在上述类型中的修改）
release: 发布新版本

scope

commit message 影响的功能或文件范围, 比如: route, component, utils, build...

subject

commit message 的概述

body

具体修改内容, 可以分为多行.

footer

一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.

约定式提交规范

以下内容来源于：www.conventionalcommits.org/zh-hans/v1.…

每个提交都必须使用类型字段前缀，它由一个名词组成，诸如 feat 或 fix ，其后接一个可选的作用域字段，以及一个必要的冒号（英文半角）和空格。
当一个提交为应用或类库实现了新特性时，必须使用 feat 类型。
当一个提交为应用修复了 bug 时，必须使用 fix 类型。
作用域字段可以跟随在类型字段后面。作用域必须是一个描述某部分代码的名词，并用圆括号包围，例如： fix(parser):
描述字段必须紧接在类型/作用域前缀的空格之后。描述指的是对代码变更的简短总结，例如： fix: array parsing issue when multiple spaces were contained in string.
在简短描述之后，可以编写更长的提交正文，为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
在正文结束的一个空行之后，可以编写一行或多行脚注。脚注必须包含关于提交的元信息，例如：关联的合并请求、Reviewer、破坏性变更，每条元信息一行。
破坏性变更必须标示在正文区域最开始处，或脚注区域中某一行的开始。一个破坏性变更必须包含大写的文本 BREAKING CHANGE，后面紧跟冒号和空格。
在 BREAKING CHANGE: 之后必须提供描述，以描述对 API 的变更。例如： BREAKING CHANGE: environment variables now take precedence over config files.
在提交说明中，可以使用 feat 和 fix 之外的类型。
工具的实现必须不区分大小写地解析构成约定式提交的信息单元，只有 BREAKING CHANGE 必须是大写的。
可以在类型/作用域前缀之后，: 之前，附加 ! 字符，以进一步提醒注意破坏性变更。当有 ! 前缀时，正文或脚注内必须包含 BREAKING CHANGE: description

示例

fix（修复BUG）

每次 git commit 必须加上范围描述。

例如这次 BUG 修复影响到全局，可以加个 global。如果影响的是某个目录或某个功能，可以加上该目录的路径，或者对应的功能名称。

// 示例1
fix(global):修复checkbox不能复选的问题
// 示例2 下面圆括号里的 common 为通用管理的名称
fix(common): 修复字体过小的BUG，将通用管理下所有页面的默认字体大小修改为 14px
// 示例3
fix(test): value.length -> values.length

feat（添加新功能或新页面）

feat(主页): 添加网站主页静态页面

这是一个示例，假设对任务静态页面进行了一些描述。
 
这里是备注，可以是放 BUG 链接或者一些重要性的东西。

chore（其他修改）

chore 的中文翻译为日常事务、例行工作。顾名思义，即不在其他 commit 类型中的修改，都可以用 chore 表示。

chore: 将表格中的查看详情改为详情

其他类型的 commit 和上面三个示例差不多，在此不再赘述。

前端工程化之 Git Hooks 管理

git-hooks

Git hooks

Husky

使用 huskey

lint-staged

安装与使用

Prettier

安装与使用

ESLint

安装与使用

配置

commitlint

安装与使用

更多配置内容

具体配置

commit

type

scope

subject

body

footer

约定式提交规范

示例

fix（修复BUG）

feat（添加新功能或新页面）

chore（其他修改）