如何配置 Git 提交代码检查?

更新日期: 2022-04-28阅读: 612标签: git

今天来看看如何使用 commitlint + Husky 在 git commit 时规范提交信息!

1. 基本概述

在多人协同的团队中,规范化的提交信息更易读,便于查找。每个人的 git commit 的信息不一样,没有一个机制就很难保证规范化。而 commitlint 就可以帮助我们解决这个问题。Commitlint 是一个自动化工具,它可以用来检查提交约定,如果提交不符合规范,则会拒绝该提交。当然,这些规则是可以配置的。

使用 commitlint 的优点:

  • 自动变更日志:由于遵循标准约定的提交,可以使用standard-version 等工具自动生成变更日志;
  • 更好的理解提交:具有特定类型和范围的提交将帮助我们了解提交更改了哪些代码;
  • 遵守特定约定:多人协作的的大项目中,commitlint 可以阻止不规范的提交,以便提交遵守定义的约定。

Git 允许开发人员在触发特定事件时执行一些操作,它被称为git hook。我们可以在git工作流程的很多阶段执行操作,例如:

  • pre-commit
  • pre-push
  • pre-rebase
  • post-update

然而,这需要在本地的 .git 文件中配置的,因此在默认情况下,每个开发人员都需要安装需要的 hook,这样才能执行特定的检查。幸运的是,Husky 可以帮助我们解决这个问题,husky 可以让我们在项目中方便添加 git hooks。Husky 不仅可以用于强制执行提交约定,还可以在提交时运行静态代码分析、测试、自动代码格式化等。

因此我们可以使用Husky和commitlint来检查提交信息是否符合提交规范。

2. 安装配置

由于 Commitlint 使用了 Husky,我们需要先安装它。Husky 是作为开发依赖项提供的,因此它仅在本地使用,不会与生产代码捆绑在一起。在终端中执行以下命令来安装Husky:

// 使用npm安装
npm install --save-dev husky

// 使用yarn安装
yarn add husky --dev

现在我们需要定义一个 Hook 来检查提交信息,这个 hook 叫做 commit-msg,需要在 package.json 中定义:

"husky": {
  "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
}

或者,我们也可以项目的根目录定义一个.huskyrc配置文件,在这个配置文件中单独定义 Husky 配置:

{
  "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
}

这段代码就告诉git hooks,当我们执行 git commit -m 'message' 时将触发commit-msg 事件钩子并通知 husky,从而执行 commitlint -e $GIT_PARAMS命令。该命令会读取commitlint.config.js 配置的规则并对提交的信息进行校验,若校验不通过,就会在终端中输出错误,commit 被终止。

有了 Husky,接下来就需要安装 Commitlint CLI,它将由 Husky hook 执行以验证提交消息:

// 使用npm安装
npm install --save-dev @commitlint/cli

// 使用yarn安装
yarn add @commitlint/cli --dev

Commitlint 只是用于检查提交消息是否符合规范的工具。所以,我们还需要一个提交规范。这个配置是完全可以自定义的,当然,Commitlint 提供了当前支持的配置之外的一些配置:

  • @commitlint/config-conventional
  • @commitlint/config-lerna-scopes
  • @commitlint/config-patternplate
  • @commitlint/config-angular
  • @commitlint/config-angular-type-enum

Commitlint 推荐使用 config-conventional 配置去规范 commit,安装命令如下:

// 使用npm安装
npm install --save-dev @commitlint/config-conventional

// 使用yarn安装
yarn add @commitlint/config-conventional --dev

最后一步,我们需要创建一个 Commitlint 配置文件,在文件中可以定义需要使用的配置,也就是上面刚安装的配置规范。只需要在项目的根目录创建一个名为commitlint.config.js的规范:

module.exports = {
    extends: ['@commitlint/config-conventional'],
};

到这里就完成了 Husky 和 Commitlint 的安装和配置。其执行流程如下:


3. 提交规范

Commitlint 推荐使用 config-conventional 配置,它的提交格式如下:

git commit -m <type>[optional scope]: <description>

这里面有三个参数:

  • type:必须,表示提交的改动类型;
  • optional scope:可选,表示提交的修改范围,需要使用括号包裹;
  • description:必须,表示提交的内容描述。

常见的 type 类型如下:

  • build: 影响构建组件的更改,如构建工具、依赖项、项目版本等;
  • chore: 比如构建流程、辅助工具等的更改。
  • ci: 持续集成的更改;
  • docs: 影响文档的更改。
  • feat: 引入新功能的更改。
  • fix: 修补错误的更改。
  • perf: 优化相关,比如提升性能、体验。
  • refactor: 代码重构的更改。
  • revert: 还原先前提交的更改。
  • style: 代码格式的更改(空格、格式、缺少分号等)。
  • test: 添加缺失测试或纠正现有测试的更改。

例如:

git commit -m 'feat: 增加 xxx 功能'
git commit -m 'feat(xx模块): 增加 yyy 功能'
git commit -m 'fix: 修复 xxx 问题'

下面是一个git提交信息的例子:


下面来看看config-conventional 配置是如何定义的:

module.exports = {
 parserPreset: 'conventional-changelog-conventionalcommits',
 rules: {
  'body-leading-blank': [1, 'always'],
  'body-max-line-length': [2, 'always', 100],
  'footer-leading-blank': [1, 'always'],
  'footer-max-line-length': [2, 'always', 100],
  'header-max-length': [2, 'always', 100],
  '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',
    'ci',
    'docs',
    'feat',
    'fix',
    'perf',
    'refactor',
    'revert',
    'style',
    'test',
   ],
  ],
 },
};

这里面包含了很多配置项,这些配置项由配置名和配置数组组成,数组的第一个元素是level,可选值0、1、2,0为disable,1为warning,2为error,第二个元素为是否应用与否,可选值always、never,第三个元素是配置规则。

上面是config-conventional的默认规则,我们可以在 commitlint.config.js 配置文件中覆盖这些规则:

module.exports = {
    extends: ['@commitlint/config-conventional'],
    rules: {
      'scope-case': [0, 'never'],
      'header-max-length': [0, 'always', 120]
    }
};

来源: 前端充电宝

链接: https://www.fly63.com/article/detial/11416

git入门操作,git命令的基本使用

Git是一个免费的、开放源码的分布式版本控制系统,它能以快速和效率处理从各种各样的项目。(一句话概括,就是分布式版本控制工具)

通过git命令,上传本地文件到git服务器

把本地代码上传到git的方法:步骤一:首先进入需要上传的项目文件夹,通过命令git init初始化,步骤二:将本地文件添加到版本库中,使用命令 git add . 将文件提交到本地的暂存区,步骤三:使用命令git commit将文件提交到本地仓库...

Git忽略规则文件.gitignore_关于.gitignore配置

.gitignore 文件的作用就是告诉git, push的时候忽略指定的文件夹或者文件,例如:vue-cli脚手架创建的项目,push到github上时,不会上传node依赖文件夹,这是因为vue-cli脚手架创建的时候,自动为我们创建了 .gitignroe文件,并且为我们写好了规则。

git从远程仓库克隆dev分支到本地的实现

这篇文章主要介绍git从远程仓库拉取dev分支到本地的实现【gitLab】:初始化一个本地仓库、与远程仓库建立连接 、查看本地是否具有dev分支、在本地创建分支dev并切换到该分支 、dev分支上的内容都拉取到本地

git强制覆盖master分支

在开发中,通常会保持两个分支master分支和develop分支,但是如果因为develop上面迭代太多而没有及时维护master,最后想丢弃master而直接将测试确认过的develop强推到master,该怎么操作呢?因此,做如下总结分享,希望对遇到同样问题的人用帮助。

Git 中 Reset、Revert、Checkout的区别

git reset 、 git checkout 和 git revert 是Git中常用命令。经常傻傻分不清他们之间的区别。最近工作不忙,抽出时间参考了其他文档,对其总结了下。传给 git reset 和 git checkout 的参数决定了它们的作用域。

git workflow

Git与SVN的比较,Gitflow为不同的分支分配一个很明确的角色,并定义分支之间如何和什么时候进行交互。新的功能分支应该从develop分支迁出一个feature分支,新功能开发完成之后再合并回develop分支,常用命令:

项目中常用的git指令

1.新建一个本地分支并切换到新建的那个分支:2.从一个分支切换到另一个分支:3.将代码恢复到最近的一次commit 时候的状态:4.将代码从最近的一次commit的状态恢复到最新的进度:

总结Git 不同情况下撤销和如何回滚

在未进行git push前的所有操作,都是在“本地仓库”中执行的。我们暂且将“本地仓库”的代码还原操作叫做“撤销”,进行git push,即已推送到“远程仓库”中。我们将已被提交到“远程仓库”的代码还原操作叫做“回滚”!注意:对远程仓库做回滚操作是有风险的,需提前做好备份和通知其他团队成员!

.gitignore的使用手册

避免将不必要的文件添加到版本管理系统中,比如前端的node_modules目录,该目录包含大量文件,如果将其添加到版本管理系统中,会使仓库变的庞大,不利于仓库的管理。

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!