Git Commit Message 应该怎么写？

Posted 欧怼怼

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Git Commit Message 应该怎么写？相关的知识，希望对你有一定的参考价值。

因为入职至今，公司也没有太规定一个代码提交规范，所以一直以来，我代码提交的commit message都是简单的一句话说明了本次代码改动内容，有时候会更加精简。

但时间长了之后，当我需要回头找一下某次提交记录的时候，就会发现不太好找，首先没有一个具体的分类，比如是添加功能、还是修复bug、还是更新文档等等；其次就是有一些message写得不是很清晰，不太能一眼明了那次改动是什么内容。

后来决定，需要重新学一学关于commit message的写法规范。

Commit Message的好处

  • 每一条提交记录的message能够提供更多的有效信息，方便我们快速浏览；
  • 可以使用git log --grep <keyword>过滤掉某些commit，便于快速查找信息；
  • 可以直接从commit生成Change log。

Commit Message格式

目前Commit Message规范使用较多的是Angular团队的规范，继而衍生了Conventional Commits sepcification。

Commit Message包括三个部分：Header、Body和Footer。格式如下：

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

其中，Header是必填的，Body和Footer可以省略不写。

Header

Header包含三个部分：type、scope和subject。其中scope是可选项。

<type>(<scope>): <subject>

# example
feat($route): add support for the `reloadOnUrl` configuration option

type

type是用于说明commit的类别，具体的标识如下：

  • feat： 一个新的功能（feature）；
  • fix：修复bug;
  • docs：修改文档，比如README.md、CHANGELOG.md等；
  • style: 修改代码的格式，不影响代码运行的变动，比如空格、格式化代码、补齐句末分号等等；
  • refactor: 代码的重构，没有新功能的添加以及bug修复的代码改动；
  • perf：优化代码以提高性能；
  • test：增加测试或优化改善现有的测试；
  • build：修改影响项目构建文件或外部依赖项，比如npm、gulp、webpack、broccoli等；
  • ci：修改CI配置文件和脚本；
  • chore：其他非src路径文件和测试文件的修改，比如.gitignore、.editorconfig等；
  • revert：代码回退；

scope

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

如果你的修改影响了不止一个scope，就可以使用*代替。

subject

subject是commit的目的简单描述，不超过50个字符，结尾不需要句号。

Body

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

Body部分应该说明代码变动的动机，以及与以前行为的对比。

More detailed explanatory text, if necessary.  Wrap it to about 72 characters or so. 

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Use a hanging indent

Footer

Footer部分主要用于两种情况：不兼容变动和处理Issue。

不兼容变动

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

BREAKING CHANGE: Previously, $compileProvider.preAssignBindingsEnabled was set to true by default. This means bindings were pre-assigned in component constructors. In Angular 1.5+ the place to put the initialization logic relying on bindings being present is the controller $onInit method.

To migrate follow the example below:

Before:

​```js
angular.module(\'myApp\', [])
    .component(\'myComponent\', {
            bindings: {value: \'<\'},
            controller: function() {
            this.doubleValue = this.value * 2;
        }
});
​```

After:
​```js
angular.module(\'myApp\', [])
    .component(\'myComponent\', {
            bindings: {value: \'<\'},
            controller: function() {
                    this.$onInit = function() {
                        this.doubleValue = this.value * 2;
                    };
                }
        });
        this.doubleValue = this.value * 2;
        };
    }
});
​```

Don\'t do this if you\'re writing a library, though, as you shouldn\'t change global configuration then.

处理Issue

如果当前commit是针对处理某个issue，那么可以在Footer部分标注处理的issue。

Fixes #234

如果想关闭这个issue的话：

Closes #234

相关插件

Commitizen - 快速编写 Commit Message

https://github.com/commitizen...

我们可以利用第三方插件Commitizen来快速编写我们的Commit Message。

首先全局安装一下Commitizen。

npm i -g commitizen

然后在我们的项目路径下，运行下列命令，使其支持Angular的Commit Message格式。

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

安装完成后，我们每次提交代码，就不再使用git commit -m命令了，而是使用git cz来执行操作。

git cz

先选择一下Commit Type，然后回车确定。

cz-cli@4.2.4, cz-conventional-changelog@3.3.0

? Select the type of change that you\'re committing: (Use arrow keys)
❯ feat:     A new feature
  fix:      A bug fix
  docs:     Documentation only changes
  style:    Changes that do not affect the meaning of the code (white-space, for
matting, missing semi-colons, etc)
  refactor: A code change that neither fixes a bug nor adds a feature
  perf:     A code change that improves performance
(Move up and down to reveal more choices)

然后输入scope的信息。

What is the scope of this change (e.g. component or file name): (press enter to skip)

然后输入subject信息。

Write a short, imperative tense description of the change (max 85 chars):

紧接着配置Boby的信息。

Provide a longer description of the change: (press enter to skip):

? Are there any breaking changes? Yes

? A BREAKING CHANGE commit requires a body. Please enter a longer description of
 the commit itself:

最后配置Footer信息。

Describe the breaking changes:

? Does this change affect any open issues? Yes
? Add issue references (e.g. "fix #123", "re #123".):

Commitlint — 校验你的 Commit Message

https://github.com/marionebl/...

Commitlint可以帮助我们检查Commit Messages, 如果我们提交的不符合指向的规范的话，就会直接拒绝提交。

因此，我们也需要向它提供一份校验的配置，这里推荐 @commitlint/config-conventional (符合 Angular团队规范)。

安装：

npm i -D @commitlint/config-conventional @commitlint/cli

同时需要在项目目录下创建配置文件.commitlintrc.js，写入：

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

更多相关配置可以去查阅一下官方文档。

Standard Version — 自动生成 CHANGELOG

https://github.com/convention...

当我们的 Commit Message 符合 Angular团队规范的情况下，我们就可以借助standard-version这样的工具，自动生成 CHANGELOG，甚至是语义化的版本号(Semantic Version)。

安装：

npm i -S standard-version

package.json配置：

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

以上是关于Git Commit Message 应该怎么写？的主要内容，如果未能解决你的问题，请参考以下文章

我是怎么写 Git Commit message 的？

Git 的 commit message 写错了，有办法进行修改么

如何写好Git Commit Message

git commit时message的问题

优雅的提交你的 Git Commit Message

简单使用Commitizen-规范你的commit message