Table of Contents generated with DocToc

• 一、commitizen
• 二、commitlint校验
• 三、husky 钩子工具
• 四、prettier 格式美化
• 五、结合tslint
• 六、lint-staged
• 七、自动化生成changelog
• 八、自动生成版本号standard-version
• 九、常用scripts
• 十、 最佳实践

一、commitizen

Commitizen是一个撰写合格 Commit message 的工具， （公约适配器）

安装：

npm install commitizen -g

使用默认（Angular ）公约配置

commitizen init cz-conventional-changelog --save-dev --save-exact

以上命令主要做了三件事：

1. 安装工具到npm模块
2. 添加到package.json依赖
3. 在package.json添加配置项

...
"config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
}

配置也可以单独成文件,文件名为.czrc 或 .cz.json, Commitizen会默认去找此文件路径下的配置。可以执行以下命令，来形成配置文件：

echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc

运行我们预设的commit/commit:all命令，即可进入commit-message手动编辑操作:

自定义配置

安装cz-customizable插件

npm i cz-customizable -D

修改commitizen默认配置项为

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

创建cz-config.js填写自定义配置。

module.exports = {
  // 重写提交类型（types）
  types: [
    {value: 'upd', name: 'upd(更新): 更新特性，非feat也非fix'},
    ...],
  // 重写提示消息(messages)
  messages: {
    type: '选择提交类型:',
    ...
  },
  // 其他配置
  ...
};

自定义规则 参考这里。

自定义后：

二、commitlint校验

有规范自然有校验，先安装校验工具：

npm install --save-dev @commitlint/cli @commitlint/config-angular

默认校验规则也为angular标准，建立配置文件：

echo "module.exports = {extends: ['@commitlint/config-angular']};" > commitlint.config.js

配置文件名（.commitlintrc.js, .commitlintrc.json,  .commitlintrc.yml）或者直接在package里的配置

自定义校验规则

我们定义了提交规范，当然也需要自定义符合提交规范的校验规则。

安装

npm install --save-dev @commitlint/config-conventional

修改commitlint.config.js中的配置

module.exports = {
    extends: ['@commitlint/config-conventional'],
    rules: [
        // 自定义规则写在这里
        // rule配置说明:：rule由name和配置数组组成，如：'name:[0, 'always', 72]'，数组中第一位为level，可选0,1,2，0为disable，1为warning，2为error，第二位为应用与否，可选always|never，第三位该rule的值。
    ]
}

自定义规则 参考这里。

三、husky 钩子工具

安装

npm install --save-dev husky

配置：

// package.json
{
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  }
}

同理可使用.huskyrc等配置文件。

commit-msg配置项每次都会在提交的时候执行，通过-E|--env传递HUSKY_GIT_PARAMS到commitlint对相关提交信息文件进行校验。

敲黑板了

husky高版本在mac上使用sourcetree提交代码时执行钩子很可能会遇到绕过钩子（在本人mac上是提示npx找不到环境变量）等报错：

如果遇到这类问题，解决方案有两种：

1. 在终端使用如下命令打开sourcetree

open /Applications/SourceTree.app/Contents/MacOS/SourceTree

网上查了半天，原因如下

大致意思是用系统命令行工具启动sourcetree会将node环境变量带入其自带的命令行，所以可以获取到。

2. 使用低版本的husky包，并且固定版本。网上有人用3.1.0解决这个问题，但是本人电脑上试验表示不行，用的是1.3.0版本。

提交一个不符合要求的commit：

值得注意的是：

通过钩子去检验commit message完全是一个君子行为，我们大可用命令或者使用sourcetree的选项（本质也是添加命令后缀）来规避掉检查。但是为了方便定位问题、形成日志，请大家务必遵守。

四、prettier 格式美化

JavaScript · TypeScript · Flow · JSX · JSON CSS · SCSS · Less HTML · Vue · Angular GraphQL · Markdown · YAML

npm install --save-dev --save-exact prettier

创建一个空的配置文件，以便自定义

echo {}> .prettierrc.json

创建一个忽略文件，来忽略一些不需要格式化的文件

echo dist >  .prettierignore

exp:

foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());

格式化之后

foo(
  reallyLongArg(),
  omgSoManyParameters(),
  IShouldRefactorThis(),
  isThereSeriouslyAnotherOne()
);

五、结合tslint

prettier项目中一般配合eslint或者tslint使用

防止冲突

npm install --save-dev tslint-config-prettier

抛错

npm install --save-dev tslint-plugin-prettier

配置项：

{
  "extends": ["tslint:latest", "tslint-config-prettier"],
  "rulesDirectory": [
    "tslint-plugin-prettier"
  ],
  "rules": {
    "prettier": true
  }
}

注：tslint-config-prettier一定要放最后

// 使用prettier修复相关 npm install --save-dev prettier-tslint

六、lint-staged

项目比较大的时候，不能每一次提交都对整个项目文件进行格式检查修复，此时就需要用到lint-staged模块。

npm install lint-staged --save-dev

package.json中添加配置

...
"lint-staged": {
    "src/**/*.ts": [
      "tslint --fix",
      "git add"
    ]
  }

在提交时候触发，所以在提交钩子也需要做配置

...
 "husky": {
    "hooks": {
      ...
      "pre-commit": "lint-staged"
    }
  },

在运行过程中，有可能会遇到找不到命令的问题

/bin/sh: lint-staged: command not found

解决方案：

1. 重装husky，注意版本和在sourcetree中的可使用性
2. 运行以下命令，但是需注意删除多余配置

npx mrm lint-staged

七、自动化生成changelog

安装

npm install conventional-changelog-cli -D

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

以上命令中参数-p angular用来指定使用的 commit message 标准，假如想使用atom的标准，则是：

conventional-changelog -p atom -i CHANGELOG.md -s

上面这条命令产生的 changelog 是基于上次 tag 版本之后的变更（Feature、Fix、Breaking Changes等等）所产生的，所以如果你想生成之前所有 commit 信息产生的 changelog 则需要使用这条命令：

conventional-changelog -p angular -i CHANGELOG.md -s -r 0

其中 -r 表示生成 changelog 所需要使用的 release 版本数量，默认为1，全部则是0。

八、自动生成版本号standard-version

standard-version 是一款遵循语义化版本（ semver）和 commit message 标准规范 的版本和 changlog 自动化工具。通常情况线下，我们会在 master 分支进行如下的版本发布操作：

1. git pull origin master
2. 根据 pacakage.json 中的 version 更新版本号，更新 changelog
3. git add -A, 然后 git commit
4. git tag 打版本操作
5. push 版本 tag 和 master 分支到仓库

其中2，3，4则是 standard-version 工具会自动完成的工作，配合本地的 shell 脚本，则可以自动完成一系列版本发布的工作了。

使用

standard-version

执行 standard-version 命令，我们会在控制台看到整个执行流程的 log 信息，在这里几个常用的参数需要注意下:

1. --release-as -r 指定版本号

默认情况下，工具会自动根据 主版本（major）,次版本（ minor） or 修订版（patch） 规则生成版本号，例如如果你package.json 中的version 为 1.0.0, 那么执行后版本号则是：1.0.1。自定义可以通过：

standard-version -r minor
# output 1.1.0

standard-version -r 2.0.0
# output 2.0.0

standard-version -r 2.0.0-test
# output 2.0.0-test

2. --prerelease, -p 预发版本命名

用来生成预发版本, 如果当期的版本号是 2.0.0，例如

standard-version --prerelease alpha
# output 2.0.0-alpha.0

3. --tag-prefix, -t 版本 tag 前缀

用来给生成 tag 标签添加前缀，例如如果前版本号为 2.0.0，则：

standard-version --tag-prefix "stable-"
# output tag: stable-v2.0.0

以上这几个参数可能我们用的比较多，还有其他选项可以通过 standard-version --help查看。

九、常用scripts

{
    ...
    "scripts": {
        "changelog:all": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0",
        "changelog": "conventional-changelog -p atom -i CHANGELOG.md -s",
        "lint": "tslint src/**/*.ts",
        "fix": "tslint src/**/*.ts --fix",
        "commit:all": "git add . & git cz",
        "commit": "git cz"
    }
}

• changelog:all 生成所有日志
• changelog 在上一个生成的日志基础上生成新的日志
• lint 检查文件是否有违lint规则
• fix 自动修改检查出的格式问题
• commit:all 暂存所有文件并提交
• commit 单个提交（同样触发commitizen）

十、 最佳实践

• One Thing，One Commit；

在提交 commit 的时候尽量保证这个 commit 只做一件事情，比如实现某个功能或者修改了配置文件, 可以更方便地cherry-pick和reset相关的代码。

• 经常commit；

经常使用commit能够使你的commit（里的修改内容）越小，并且能使你commit相关的修改，多次commit允许你推送自己代码到远程分支上的频率增加，能有效的减少merge代码时出现的代码冲突问题，因为多次 commit能使你的同事的代码库得到及时的更新。

• 不要commit一半的工作；

当开发任务没有完整的完成的时候，不要commit。 这个开发任务颗粒度需要自己把控，但是无论颗粒度大小，不要提交一般的工作，必要的时候可以用stash命令来保存进行到一半的修改。

• commit之前的测试；

保证你所开发的功能是完整无误的。在commit代码之前的对代码进行充分review和测试，可以避免有问题的代码被其他开发人员使用。

• 编写规范的commit message；

规范的Commit Message可以让自己和合作伙伴更快地了解开发情况，也便于后期的规范的changelog和版本迭代。