Git 提交规范

在Git的整个流程中，commit作为一个必经之路，要求每次都必须说明这次提交的内容。但据我观察，长时间以来大部分程序员对此并不上心，经常出现不知所云的Commit message（类似：http://www.commitlogsfromlastnight.com/）。

为了避免这种糟糕的Commit message，是时候引入一个新的规范了（并不新。

01 作用

采用这种规范还有以下的好处：

  1. 通过脚本生成CHANGELOG.md

    在Angular规范中，他们使用了new features, bug fixes, breaking changes三个部分作为changlog的骨架。这一点可以作为参考。

  2. 在git bisect时过滤不重要的commit

    小的格式更改（加几个空格、空行，改一下缩进，加几句注释等等）可以被直接过滤掉。

  3. 治愈你幼小的♥

02 格式

Commit message包括三个部分：Header、Body和Footer。

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

其中，header 是必需的，body 和 footer 可以省略。 不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。

特殊情况：

如果这一次提交的内容时回滚到了之前某一次的提交，它的格式会有所不同（如下）。

revert：[回滚到那个版本的header]

This reverts commit <hash>

此处hash为被撤销 commit 的 SHA 标识符。

2.1 Header

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

其中，type说明commit的类别：

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

如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。

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

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

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

2.2 Body

Body 部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。

有两个注意点。

（1）使用第一人称现在时，比如使用change而不是changed或changes。

（2）应该说明代码变动的动机，以及与以前行为的对比。

Footer 部分只用于两种情况。

2.3.1 不兼容变动

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

BREAKING CHANGE: isolate scope bindings definition has changed.

    To migrate the code follow the example below:

    Before:

    scope: {
      myAttr: 'attribute',
    }

    After:

    scope: {
      myAttr: '@',
    }

    The removed `inject` wasn't generaly useful for directives so there should be no code using it.

2.3.2 关闭 Issue

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

Closes #234

也可以一次关闭多个 issue 。

Closes #123, #245, #992

03 工具