前言

Git 作为目前开源社区最为火热的分布式系统版本管理工具，当我们在提交代码之前，都是需要添加 Commit message（提交说明），否则就不允许提交。

1
$ git commit -m "hello world"

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

如果一行不够，可以只执行 git commit，就会跳出文本编辑器，让你写多行。如

1
$ git commit

基本上，你写什么都行。
iamge

我们先来看下平时提交的 commmit 日志，只是简单的说明本次提交的信息，如
iamge

我们再来看下具有一定规范性的 commit 日志，是不是更加清晰明了，有了一定的规范，对提交类型做了区分。
image

一般来说，commit message 应该清晰明了，说明本次提交的目的。

目前，社区有多种 Commit message 的写法规范。这种是 Angular 规范，中文。这是目前使用最广的写法，是比较合理和系统化，并且有配套的工具。

作用

  • 提供更多的历史信息，方便快速浏览。
  • 可以过滤某些 commit（比如文档改动），便于快速查找信息。
  • 可以直接从 commit 生成 Change log。

标准 Commit Message 规范

格式

1
2
3
4
5
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

每次提交可以包含页眉(header)、正文(body)和页脚(footer)。其中，Header 是必需的。

每次提交的信息不超过 100 个字符，如

1
2
3
4
5
6
7
8
9
commit f477xxxxxxxba558 (HEAD -> master)
Author: heiemooa <xxxxxxxxx@qq.com>
Date:   Fri Jun 4 15:48:29 2021 +0800

    feat: 🎸 添加新功能

    新功能详情介绍

    BREAKING CHANGE: 🧨 footer

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

  • type 用于说明 commit 的类别
1
2
3
4
5
6
7
8
9
10
11
12
$ git cz
? Select the type of change that you're committing: (Use arrow keys or type to search)
❯ 💍  test:       Adding missing tests                                    // 添加缺失的测试
  🎸  feat:       A new feature                                           // 新功能（feature）
  🐛  fix:        A bug fix                                               // bug 修复
  🤖  chore:      Build process or auxiliary tool changes                 // 构建过程或辅助工具更改
  ✏️  docs:       Documentation only changes                              // 文档
  💡  refactor:   A code change that neither fixes a bug or adds a feature// 重构（不修复错误,不添加功能的代码更改）
  💄  style:      Markup, white-space, formatting, missing semi-colons... // 标记、空格、格式、缺少分号
  🎡  ci:         CI related changes                                      // CI相关的变化
  ⚡️  perf:       A code change that improves performance                 // 提高性能的代码更改

  • scope，用于说明 commit 影响的范围
  • subject 是 commit 目的的简短描述，一般不超过 50 个字符。

Body

Body 部分是对本次 commit 的详细描述，可以分成多行

Footer 部分只用于两种情况。

  • 不兼容变动
    如果当前代码与上一个版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述
  • 关闭 Issue
    如果当前 commit 针对某个 issue，那么可以在 Footer 部分关闭这个 issue 。
    1
    2
    3
    4
    // 单个
    Closes #123
    // 支持多个
    Closes #123, #245, #992

开始

上诉 commit 规范看起来是不很麻烦，这里推荐使用一些开源的工具进行管理，我们先来看一下效果
image

安装插件

方式一

commitizen – 自动生成合格的 commit message

commitizen 是一个撰写合格 Commit message 的工具，通过 commitizen 我们可以快速生成符合规范的 commit message，下面我们介绍下怎么在项目中使用。

  • 安装
1
$ npm install -g commitizen
  • 在项目目录里，运行下面的命令，使其支持 Angular 的 Commit message 格式。
1
$ commitizen init cz-conventional-changelog --save --save-exact

如果出现报错

1
2
Attempting to initialize using the npm package cz-conventional-changelog
Error: A previous adapter is already configured. Use --force to override

可以在指令后面加上 –force

方式二

git-cz – 插件全局安装

安装git-cz工具，也可用快速生成符合规范的 commit message。

1
2
$ npm install -g git-cz
$ git-cz

生成 CHANGE LOG

如果需要生成发布记录，可以通过 conventional-changelog-cli 生成。一般情况下，生成的文档包括

  • New features
  • Bug fixes
  • Breaking changes.

其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。

安装

1
$ npm install -g conventional-changelog-cli

修改 package.json

1
2
3
4
"scripts": {
  "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s",
  "changelog-all": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
},

生成 CHANGELOG.md

1
2
$ npm run changelog // 不会覆盖以前的 Change log，只会在CHANGELOG.md的头部加上自从上次发布以来的变动。
$ npm run changelog-all // 生成所有发布的 Change log