Git提交规范 | Joey Z. - AI 产品开发工程师

为什么需要提交规范

在团队协作中，如果Git的提交说明精准，在后期协作以及Bug处理时会变得有据可查，项目的开发可以根据规范的提交说明快速生成开发日志，从而方便开发者或用户追踪项目的开发信息和功能特性。

提交说明的结构

提交说明包含三个部分：Header、Body 和 Footer。

<Header>

<Body>

<Footer>

Header部分包含三个字段：type（必需）、scope（可选）和subject（必需）。

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

type

type用于说明commit的类别，只允许使用下面7个标识：

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

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

subject

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

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

Body

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

有两个注意点：

使用第一人称现在时，比如使用change而不是changed或changes
应该说明代码变动的动机，以及与以前行为的对比

Footer部分只用于两种情况：

不兼容变动

如果当前代码与上一个版本不兼容，则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.

关闭Issue

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

Closes #234

也可以一次关闭多个issue。

Closes #123, #245, #992

示例

feat(browser): onUrlChange event (popstate/hashchange/polling)

Added new event to browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available

Closes #123, #305, #392

fix(release): need to depend on latest rxjs and zone.js

The version in our package.json gets copied to the one we publish, and users need the latest of these.

docs(changelog): update change log to beta.5

style(router): fix linting errors

refactor(core): rename onInit to ngOnInit

chore(deps): bump rxjs from 5.0.0-beta.2 to 5.0.0-beta.6

总结

规范的Git提交说明可以帮助团队成员更好地理解和遵循统一的提交标准，提高团队协作效率，也为后期的项目维护提供了便利。