勿助勿忘，深造自得

0%

Git提交日志规范

发表于 更新于 分类于

git commit -m “commit message” 每次提交的时候，总得写点什么，如果团队中小伙伴都按一定的范式来书写提交记录，问题追溯将变的有迹可循；

目前，社区有多种 Commit message 的规范。不过一般采用较多的是Google的AngularJS的规范，有现配套的工具来实现规范化提交。

为什么要提交结构化的Commit message？

结构化的commit message ，有3点好处：

  • 提供更多的历史信息，方便快速浏览和问题追溯；
    • git log <last tag> HEAD --pretty=format:%s
  • 可以按类型过滤，便于快速查找信息；
    • git log <last release> HEAD --grep feature
  • 可以直接根据commit message生成Change log；
    • conventional-changelog -p angular -i CHANGELOG.md -s -p

怎么写结构化的Commit message？

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

其中，Header 是必填，Body 和 Footer 是选填。

Header 包括三个字段：type（必填）、scope（选填）和 subject（必填）。

type

  • feat：新增feature；
  • fix：修复bug；
  • docs：仅仅修改了文档，如修改了readme.md；
  • style：仅仅修改了代码格式，未改变代码逻辑；
  • refactor：代码重构，未新增功能或修复bug；
  • test：测试用例新增/更新；
  • chore：改变构建流程、或增加依赖库、工具等；
  • revert：版本回滚；

如果type 为 feat或fix，则该 commit 会生成到在 Change log 中。

scope

scope 用于说明 commit 影响的范围，比如dao、controller、dto等等，具体视项目情况而定。

subject

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

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

Body

Body 部分是对本次 commit 的更详细的说明文本，建议72个字符以内。

内容包括但不限于:

  • 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等；
  • 如何解决这个问题? 具体描述解决问题的步骤；
  • 是否存在副作用、风险?

footer 部分只用于两种情况

  • 不兼容变动：如果当前代码与上一个版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。
  • 关闭Issuce：如果当前 commit 针对某个 issue，那么可以在 Footer 部分关闭这个 issue；
    • Closes #123, #245, #992

规范化Commit Message的配套工具

Commitizen自动生成合格的 commit message

  • 安装：npm install -g commitizen
  • 使用
    • 如果不是node项目，需新增一个package.json，内容写入{}；
    • commitizen init cz-conventional-changelog --save --save-exact：初始化，使其支持angular的commit message格式；
    • git cz：以后凡是用到git commit命令，一律改为使用git cz。这样就能按提示一步步写出符合格式的 Commit message了。

参考