git commit检查

时间:2021-2-20 作者:admin

git commit检查

1. 规范 commit 信息

我们可以利用 commitizenhusky 来规范代码库的 commit

安装以下依赖:
npm install @commitlint/cli @commitlint/config-conventional husky  -D

如果你还没有安装过 commitizen,那么先全局安装:

npm install commitizen -g

Next, initialize your project to use the cz-conventional-changelog adapter by typing:

接下来,初始化项目的依赖json以便添加cz-conventional-changelog,使用npm

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

使用yarn

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

如果不想用规范化commit,可以直接在 git commit -m –force,如果需要更多帮助,输入commitizen help

以上的操作是为了

  1. 安装 cz-conventional-changelog
  2. 将其作为依赖保存到package.json’s
  3. config.commitizen作为key保存到package.json
...
  "config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
  }
在 package.json 中增加 husky 字段。
{
    "husky": {
        "hooks": {
            "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
        }
    },
}

huskygit hook 工具,使用 husky,我们可以方便的在 package.json 中配置 git hook 脚本,例如: pre-commitpre-pushcommit-msg 等的。

创建 commitlint.config.js 文件
module.exports = {
    extends: ["@commitlint/config-conventional"],
};

此刻开始,请使用 git cz 来替代 git commit 提交信息,我们来看看,假设我们随便写一个 git commit -m 'fixbug' 会提示什么?

使用 git cz 来进行填写 commit 的内容。

git cztype 说明:

虽然,我们现在已经可以规范提交信息了,但是我们可能不喜欢默认的交互,例如,一个精简的描述就可以了,不希望再提示我去写详细的描述,那么就可以使用 cz-customizable 来进行定制。

自定义提交说明

安装 cz-customizable
npm install cz-customizable -D

cz-customizable 是可自定义的 Commitizen 插件,可帮助实现一致的 commit message

cz-customizable 适合大型团队去自定义 scope,和 commit type

新建 .cz-config.js

在项目根目录下创建 .cz-config.js 文件:

官方提供了一份配置信息,可以去这个地址查看:github.com/leoforfree/…

//.cz-config.js
module.exports = {
  types: [
    { value: 'feat', name: 'feat:     A new feature' },
    { value: 'fix', name: 'fix:      A bug fix' },
    { value: 'docs', name: 'docs:     Documentation only changes' },
    {
      value: 'style',
      name:
        'style:    Changes that do not affect the meaning of the code\n            (white-space, formatting, missing semi-colons, etc)',
    },
    {
      value: 'refactor',
      name: 'refactor: A code change that neither fixes a bug nor adds a feature',
    },
    {
      value: 'perf',
      name: 'perf:     A code change that improves performance',
    },
    { value: 'test', name: 'test:     Adding missing tests' },
    {
      value: 'chore',
      name:
        'chore:    Changes to the build process or auxiliary tools\n            and libraries such as documentation generation',
    },
    { value: 'revert', name: 'revert:   Revert to a commit' },
    { value: 'WIP', name: 'WIP:      Work in progress' },
  ],

  scopes: [{ name: 'accounts' }, { name: 'admin' }, { name: 'exampleScope' }, { name: 'changeMe' }],

  allowTicketNumber: false,
  isTicketNumberRequired: false,
  ticketNumberPrefix: 'TICKET-',
  ticketNumberRegExp: '\\d{1,5}',

  // it needs to match the value for field type. Eg.: 'fix'
  /*
  scopeOverrides: {
    fix: [
      {name: 'merge'},
      {name: 'style'},
      {name: 'e2eTest'},
      {name: 'unitTest'}
    ]
  },
  */
  // override the messages, defaults are as follows
  messages: {
    type: "Select the type of change that you're committing:",
    scope: '\nDenote the SCOPE of this change (optional):',
    // used if allowCustomScopes is true
    customScope: 'Denote the SCOPE of this change:',
    subject: 'Write a SHORT, IMPERATIVE tense description of the change:\n',
    body: 'Provide a LONGER description of the change (optional). Use "|" to break new line:\n',
    breaking: 'List any BREAKING CHANGES (optional):\n',
    footer: 'List any ISSUES CLOSED by this change (optional). E.g.: #31, #34:\n',
    confirmCommit: 'Are you sure you want to proceed with the commit above?',
  },

  allowCustomScopes: true,
  allowBreakingChanges: ['feat', 'fix'],
  // skip any questions you want
  skipQuestions: ['body'],

  // limit subject length
  subjectLimit: 100,
};

  • types: 描述修改的性质是什么,是bugfix还是feat,在这里进行定义。
  • scopes: 定义之后,我们就可以通过上下键去选择 scope
  • scopeOverrides: 针对每一个type去定义scope
  • allowBreakingChanges: 如上设置为 ['feat', 'fix'],只有我们type选择了 feat 或者是 fix,才会询问我们 breaking message.
  • allowCustomScopes: 设置为 true,在 scope 选择的时候,会有 emptycustom 可以选择,顾名思义,选择 empty 表示 scope 缺省,如果选择 custom,则可以自己输入信息
  • skipQuestions: 指定跳过哪些步骤,例如跳过我们刚刚说的详细描述,设置其为 scope: ['body'],假设我们的项目也不会涉及到关联 issue,我们可以设置其为 scope: ['body', 'footer']
  • subjectLimit: 描述的长度限制

这里我就不一一演示每个字段修改之后的情况了,根据字段的说明,建议如果想自定义提交规则,在本地进行修改验证,公司内部的代码库不需要管理 issue,另外,我不喜欢写长描述,所以我把 bodyfooterskip 掉了。

cz-customizable 会首先在项目根目录下寻找: .cz-config.js.config/cz-config.js,如果找不到,会去主目录寻找。我们也可以在 package.json 中手动去指定配置文件的路径。

"config": {
    "commitizen": { 
        "path": "node_modules/cz-customizable"
    },
    "cz-customizable": {
        "config": "config/path/to/my/config.js"
    }
}

现在,我们已经规范了 commit 信息,但是没有对提交的代码进行规范,在一个代码库中,经常出现2个空格/4个空格混用,有些地方写 ;,有些不写 ;,风格不统一。例如,我们希望提交到git库的代码,都能够通过 eslint 检查或者是通过测试。我们可以借助于 pre-commit 这个钩子来做这些事情。

声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。