使用工具规范化代码 git 提交

约定式提交规范

使用 git 提交代码时,不同人对代码修改内容的描述不同,有些人可能描述的很详细,有些人却短短几个字只写个大概,团队其他成员看到这样的内容不能很快的确定代码做了哪些修改,所以为了团队中更好的协作和从 git log 中定位问题,定义一个 git 提交规范很有必要

较为常用的是 Conventional Commits Specification (约定式提交 规范),约定式提交规范规定,提交内容需包含以下信息:

[optional scope/可选的代码作用范围]: 

[optional body/可选的正文]

[optional footer/可选的脚注]

其中 type 和 description 为必需项。description 中用一句话描述修改的内容,type 可选择的值包括:

feat: 新增功能、新增特性,production changes
fix: 修复 bug,production changes
style: 不影响代码运行的修改(如空格、格式化、换行缩进、行尾分号等),development changes
refactor: 代码重构,既没有修复 bug 也没有新增功能的修改(删除冗余代码、简化代码、变量重命名等),development changes
perf: 只为了优化性能进行的代码修改,production changes

build: 影响项目构建(涉及脚本、配置、工具)或依赖项的修改,之前被称为 chore,也可以不设置这一项而用 chore 代替,development changes
ci: 持续集成和部署系统相关文件的修改,development changes
docs: 文档变更(包括给用户看的文档,和给内部开发人员看的文档),development changes
test: 测试用例的增加或修改,development changes

revert: 代码回滚,恢复上次提交内容,production changes
chore: 其他没有分类的更改,development changes


------
production changes:生产变更,影响最终的生产代码
development changes:开发变更,不影响最终的生产代码

正文部分详细说明做了什么修改,为什么修改等,脚注部分放 Breaking Changes 或 Closed Issues

commitizen

每次提交代码都书写以上那么详细的信息又会有些繁琐,可以使用 commitizen 这个工具提高效率,它提供了一个 git cz 来代替原有的 git commit 命令,在用它提交代码时可以填写规范中必需的字段

全局安装 commitizen:

npm install -g [email protected]

项目中安装并配置 cz-customizable:

npm i --save-dev [email protected]
// package.json
"config": {
  "commitizen": {
    "path": "node_modules/cz-customizable"
  }
}

项目根目录创建配置文件 .cz-config.js 来自定义提示内容:

module.exports = {
  // 可选类型
  types: [
    {
      value: 'feat',
      name: 'feat:     新功能'
    },
    {
      value: 'fix',
      name: 'fix:      修复bug'
    },
    {
      value: 'style',
      name: 'style:    代码格式(不影响代码运行的修改)'
    },
    {
      value: 'refactor',
      name: 'refactor: 代码重构(既不是增加feature,也不是修复bug)'
    },
    {
      value: 'perf',
      name: 'perf:     性能优化'
    },
    {
      value: 'build',
      name: 'build:    影响项目构建或依赖项的修改'
    },
    {
      value: 'ci',
      name: 'ci:       持续集成和部署系统相关文件的修改'
    },
    {
      value: 'docs',
      name: 'docs:     文档变更'
    },
    {
      value: 'test',
      name: 'test:     增加或修改测试用例'
    },
    {
      value: 'revert',
      name: 'revert:   回退代码'
    },
    {
      value: 'chore',
      name: 'chore:    其他没有分类的更改'
    }
  ],
  // 消息步骤
  messages: {
    type: '请选择提交类型:',
    customScope: '请输入修改范围(可选):',
    subject: '请简要描述提交(必填):',
    body: '请输入详细描述(可选):',
    footer: '请输入要关闭的issue(可选):',
    confirmCommit: '确认使用以上信息提交?(y/n/e/h)'
  },
  // 跳过问题
  skipQuestions: ['body', 'footer'],
  // subject文字长度默认是72
  subjectLimit: 72
}

提交代码时,使用 git cz 代替 git commit,就可以看到提示内容

使用工具规范化代码 git 提交_第1张图片

但是如果在提交代码时忘记使用了 git cz 命令,就不会使用到上边的工具和规范,可以通过 git hooks 来解决

git hooks

git hooks 指的是 git 在执行某事件前后可以进行的一些额外操作,如果希望提交代码时阻止不符合提交规范的提交内容,就可以使用 git hooks 钩子函数

git hooks 钩子函数:

Git Hook 调用时机 说明
pre-applypatch git am 执行前
applypatch-msg git am 执行前
post-applypatch git am 执行后 不影响 git am 的结果
pre-commit git commit 执行前。
它不接受任何参数,并且在获取提交日志消息并进行提交之前被调用。
脚本 git commit 以非零状态退出会导致命令在创建提交之前中止。
可以用 git commit --no-verify 绕过
commit-msg git commit 执行前。
可用于将消息规范化为某种项目标准格式。
还可用于在检查消息文件后拒绝提交。
可以用 git commit --no-verify 绕过
post-commit git commit 执行后 不影响 git commit 的结果
pre-merge-commit git merge 执行前 可以用 git merge --no-verify 绕过
prepare-commit-msg git commit 执行后,编辑器打开之前
pre-rebase git rebase 执行前
post-checkout git checkout 或 git switch 执行后 如果不使用 --no-checkout 参数,则在 git clone 之后也会执行。
post-merge git commit 执行后 在执行 git pull 时也会被调用
pre-push git push执行前
pre-receive git-receive-pack 执行前
update
post-receive git-receive-pack 执行后 不影响 git-receive-pack 的结果
post-update 当 git-receive-pack 对 git push 作出反应并更新仓库中的引用时
push-to-checkout 当 git-receive-pack 对 git push 做出反应并更新仓库中的引用时,以及当推送试图更新当前被签出的分支且 receive.denyCurrentBranch 配置被设置为 updateInstead 时
pre-auto-gc git gc --auto 执行前
post-rewrite 执行 git commit --amend 或 git rebase 时
sendemail-validate git send-email 执行前
fsmonitor-watchman 配置 core.fsmonitor 被设置为 .git/hooks/fsmonitor-watchman 或 .git/hooks/fsmonitor-watchmanv2 时
p4-pre-submit git-p4 submit 执行前 可以用 git-p4 submit --no-verify 绕过
p4-prepare-changelist git-p4 submit 执行后,编辑器启动前 可以用 git-p4 submit --no-verify 绕过
p4-changelist git-p4 submit 执行并编辑完 changelist message 后 可以用 git-p4 submit --no-verify 绕过
p4-post-changelist git-p4 submit 执行后
post-index-change 索引被写入到 read-cache.c do_write_locked_index 后

pre-commit:会在提交前被调用,并且可以按需指定是否要拒绝本次提交

commit-msg:可以用来规范化标准格式,并且可以按需指定是否要拒绝本次提交

husky + commitlint

使用 husky + commitlint 可以检查提交描述是否符合规范要求

  • commitlint:用于检查提交信息

  • husky:是 git hooks 工具

安装 commitlint:

npm install --save-dev @commitlint/[email protected] @commitlint/[email protected]

创建配置文件 commitlint.config.js:

module.exports = {
  // 继承的规则
  extends: ['@commitlint/config-conventional'],
  // 定义规则类型
  rules: {
    // type 类型定义,表示 git 提交的 type 必须在以下类型范围内
    'type-enum': [
      2,
      'always',
      [
        'feat',
        'fix',
        'style',
        'refactor',
        'perf',
        'build',
        'ci',
        'docs',
        'test',
        'revert',
        'chore'
      ]
    ],
    // subject 大小写不做校验
    'subject-case': [0]
  }
}

安装 husky:

npm install [email protected] --save-dev

生成 .husky 文件夹:

npx husky install

在 package.json 中添加 prepare 命令:

// npm set-script prepare "husky install"

  "scripts": {
    "prepare": "husky install"
  },

执行 prepare 命令:

npm run prepare

在 husky 中添加 commitlint 的 hook,并指定在 commit-msg 的 hooks 下执行 npx --no-install commitlint --edit “$1”

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

生成的 .husky/commit-msg 文件:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx --no-install commitlint --edit $1

设置到这个步骤,不符合规范的 commit 将提交失败

在 pre-commit 检测提交时代码规范

在 pre-commit hooks 函数中,可以使用 husky 配合 eslint 对代码进行检测及格式化

在 husky 中添加 commitlint 的 hook,并指定在 pre-commit 的 hooks 下执行 npx eslint --ext .js,.vue src 来进行代码检测:

npx husky add .husky/pre-commit "npx eslint --ext .js,.vue src"

生成的 .husky/pre-commit 文件:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx eslint --ext .js,.vue src

这时在 git 提交代码时若不符合 eslint 规则,git commit 将会执行失败无法提交代码

lint-staged 自动修复格式错误

使用 lint-staged 可以实现在代码提交时,只检查本次修改代码的文件而不是所有文件,并在出现错误时自动修复。使用 vue cli 创建的项目已经安装了 lint-staged

在 package.json 中配置:

  "lint-staged": {
    "src/**/*.{js,vue}": [
      "eslint --fix",
      "git add"
    ]
  },

如上配置,每次它只会在本地 commit 之前,校验提交的内容是否符合本地配置的 eslint 规则,校验会出现两种结果:

  • 如果符合规则:则会提交成功
  • 如果不符合规则:会自动执行 eslint --fix 尝试修复,如果修复成功则会提交代码,如果失败,则会提示错误

修改 .husky/pre-commit 文件为:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

这时提交代码时不符合规范的文件会被自动修复

你可能感兴趣的:(git,github)