git commit message规范与约束(全局安装)

2024-01-13 11:54:52

git commit message格式

git每次提交代码，都必须写commit message(提交说明)，用来说明本次提交的目的，否则不允许提交。

 git commit -m "hello world"

上面代码的-m 参数，就是用来指定commit message的。

commit message的写法规范有许多，本文介绍目前使用最广的，比较合理和系统化的一种规范：Angular 规范。

一、Commit message 格式

  <type>(<scope>): <subject>
  <空行>
  <body>
  <空行>
  <footer>

其中，Header 是必需的，Body 和 Footer 可以省略。

Header部分只有一行，包括三个字段：type （必需)、scope(可选)、subject（必需）

type

type 用于说明commit的类别，允许使用以下7个标识。

   feat：新功能（feature）
   fix：修补bug
   docs：文档（documentation）
   style： 格式（不影响代码运行的变动）
   refactor：重构（即不是新增功能，也不是修改bug的代码变动）
   test：增加测试
   chore：构建过程或辅助工具的变动

scope

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

subject

subject是 commit 目的的简短描述，不超过50个字符。

注意事项：

以动词开头，使用第一人称现在时，比如change，而不是changed或changes
第一个字母小写
结尾不加句号（.）

1.2 Body

Body 部分是对本次 commit 的详细描述，可以分成多行。(换行用\n)

Footer 部分只用于两种情况。

不兼容变动

如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。

关闭Issue

如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue。

  Closes #234

也可以一次关闭多个 issue 。

  Closes #123, #245, #992

二、Commitizen

我们知道了提交规范，就需要通过工具生成和约束。通过借助工具commitizen/cz-cli的安装之后，就会产生规范性的提示语句，帮助我们形成规范的commit message。

Commitizen是一个撰写合格 Commit message 的工具。

全局安装，命令如下：

  npm install -g commitizen cz-conventional-changelog

查看是否安装成功

  npm ls -g -depth=0

全局模式下, 需要 ~/.czrc 配置文件, 为 commitizen 指定 Adapter比如: cz-conventional-changelog (一个符合 Angular团队规范的 preset)。

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

安装成功后，在对应的git项目中，凡是用到git commit命令，一律改为使用git cz.这时，就会出现选项，用来生成符合格式的 Commit message。

三、校验Commit message 是否符合规范

Commitlint

commitlint用于检查我们的commit message是否符合提交规范，如果不符合，则直接拒绝提交。

全局安装

  npm install -g @commitlint/cli @commitlint/config-conventional

生成配置文件

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

你也可以在commitlint.config.js制定提交message规范

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

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', [
      "feat", "fix", "docs", "style", "refactor", "test", "chore", "revert"
    ]],
    'subject-full-stop': [0, 'never'],
    'subject-case': [0, 'never']
  }
};

上面我们就完成了commitlint的安装与提交规范的制定。但检验commit message的最佳方式是结合git hook，所以需要配合Husky。

Husky

husky继承了Git下所有的钩子，在触发钩子的时候，husky可以阻止不合法的commit,push等等。

创建package.json文件
进入到git项目中，执行

  npm init --yes

会生成项目对应项目的package.json

进入项目中，安装husky

  npm install husky

安装成功后需要在项目的package.json中配置：

  "husky": {
    "hooks": {
      "commit-msg": "commitlint -e $GIT_PARAMS"
    }
  }

然后我们正常操作git

  git add .
  git commit -m "test"

上面message不符合提交规范，所以会报错如下：

起到了校验的作用。

四、生成Change Log

如果你的所有 Commit 都符合 Angular 格式，那么发布新版本时， Change log 就可以用脚本自动生成

生成的文档包括以下三个部分。

New features
Bug fixes
Breaking changes

每个部分都会罗列相关的 commit ，并且有指向这些 commit 的链接。当然，生成的文档允许手动修改，所以发布前，你还可以添加其他内容。

conventional-changelog 就是生成 Change log 的工具。

安装changelog

  npm install -g conventional-changelog
  npm install -g conventional-changelog-cli

进入git项目目录下，执行命令：

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

以上命令中参数-p angular用来指定使用的 commit message 标准为angular，参数-i CHANGELOG.md表示生成的 changelog输出到 CHANGELOG.md 文件中。
命令执行完会在项目中生成CHANGELOG.md文件

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

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

由于命令过长，可以在package.json中配置scripts

  
{
  "scripts": {
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s"
  }
}

以后，直接运行下面的命令即可。

  npm run changelog

standard-version 也是生成 Change log 的工具。

正常情况下，版本发布流程如下：

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

conventional-changelog工具需要在手动修改了pacakage.json版本号，生成了changelog之后，手动commit及打tag。但standard-version工具会自动完成2、3、4项的工作。如果再配合本地的shell脚本，则可以自动的完成一系列的版本发布工作。

安装(推荐全局安装)

  npm i -g standard-version

在package.json中配置：

  "scirpt": {
    ...,
    "release": "standard-version"
}

使用：

  npm run release

最终会在git项目中生成CHANGELOG.md文件

跟conventional-changelog生成的文件差不多。

更详细的用法：

--first-release, -f 第一次打版本

  standard-version -f

生成与package.json中版本号一致的tag。本地不能存在一样版本号的tag。

--release-as, -r 指定版本号

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

standard-version -r minor

查看生成的tag:自动生成v4.4.0

查看提交记录：修改已经自动提交

最后提交本地代码与tag

  git push origin master
  git push origin --tags

会在github上看到提交记录与tag。

也可以固定版本：

  standard-version -r 5.0.0
  standard-version -r 5.0.0-test

会生成v5.0.0和5.0.0-test版本

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

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

  standard-version -p
  standard-version -p alpha
  standard-version -p test

会生成v4.4.1-0、v4.4.1-alpha.0、v4.4.1-test.0。其中alpha、test代表预发布版本的名称。

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

默认有一个前缀v,如果不想有任何前缀，直接用-t即可。
当前版本4.4.1

  standard-version -t "stable-"
  standard-version -t "test-"

生成：test-5.0.0、stable-5.1.0,其中 test是第一次作为前缀使用，所以会生成一个主版本。

综合使用：

  standard-version -t 'stable-' -r 6.1.0

生成 stable-6.1.0

--dry-run

  standard-version --dry-run

此命令会在允许你在后台查看将运行哪些步骤，不会修改package.json、changlog，也不会提交任何代码及生成tag。可以其他命令结合使用。

  standard-version -r 9.0.0 --dry-run

可用于查看该命令是否满足你的需求。

Lifecycle scripts 生命周期脚本

standard-version支持生命周期脚本。这些脚本允许你在发布期间去执行自己的补充命令。以下为生命周期的钩子，并按照文档顺序执行：

prerelease: executed before anything happens. If the prerelease script returns a non-zero exit code, versioning will be aborted, but it has no other effect on the process.
prebump/postbump: executed before and after the version is bumped. If the prebump script returns a version #, it will be used rather than the version calculated by standard-version.
prechangelog/postchangelog: executes before and after the CHANGELOG is generated.
precommit/postcommit: called before and after the commit step.
pretag/posttag: called before and after the tagging step.

在package.json中配置lifecycle scripts：

  {
  "standard-version": {
    "scripts": {
      "prebump": "echo 1.2.0"
    }
  }
}

执行standard-version会生成v1.2.0的版本。

跳过生命周期步骤(Skipping lifecycle steps)

You can skip any of the lifecycle steps (bump, changelog, commit, tag), by adding the following to your package.json:

  {
  "standard-version": {
    "skip": {
      "changelog": true
    }
  }
}

码农公寓

git commit message规范与约束(全局安装)

git commit message格式

一、Commit message 格式

1.1 Header

1.2 Body

1.3 Footer

二、Commitizen

三、校验Commit message 是否符合规范

Commitlint

Husky

四、生成Change Log

conventional-changelog 就是生成 Change log 的工具。

standard-version 也是生成 Change log 的工具。

--first-release, -f 第一次打版本

--release-as, -r 指定版本号

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

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

--dry-run

Lifecycle scripts 生命周期脚本

在package.json中配置lifecycle scripts：

跳过生命周期步骤(Skipping lifecycle steps)

码农公寓

git commit message格式

一、Commit message 格式

1.1 Header

1.2 Body

1.3 Footer

二、Commitizen

三、校验Commit message 是否符合规范

Commitlint

Husky

四、生成Change Log

conventional-changelog 就是生成 Change log 的工具。

standard-version 也是生成 Change log 的工具。

--first-release, -f 第一次打版本

--release-as, -r 指定版本号

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

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

--dry-run

Lifecycle scripts 生命周期脚本

在package.json中配置lifecycle scripts：

跳过生命周期步骤(Skipping lifecycle steps)

相关文章