说在前面

我们希望每个 mr 尽量⽐较单⼀，不要涉及太多复合的内容。这样便于 review，必要时也便于回滚。
这⾥定义了 mr 提交时，title 和 message 的⼀个规范，如果可以的话，最好每个 commit 都遵循这个规范。

定义规范的好处是：

• 提供更多的信息，⽅便排查与回滚;
• 过滤关键字，迅速定位.

mr title 的规范

形式化定义：

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

其中，各个域的说明如下：

• type：⽤于说明这次 mr/commit 的类别，只允许使⽤下⾯ 7 个标识(都是⼩写):

  • feat：新功能（feature）
  • fix：修补bug
  • docs：⽂档（documentation）
  • style： 格式（不影响代码运⾏的变动）
  • refactor：重构（即不是新增功能，也不是修改 bug 的代码变动）
  • perf： 性能优化
  • test：增加测试
  • chore：构建过程或辅助⼯具的变动，例如 requirement 的变动可以放到这⾥

• scope：⽤于说明 mr/commit 影响的范围，⽐如数据层、控制层、视图层等等，视项⽬不同⽽不同。
  例如，对于 phoenix，这⾥可以是 all/base/train-worker/model-manager/ml-service等。

• subject：是 mr/commit ⽬的的简短描述，不超过50个字符。⼀般来说，遵循以下规则：

  • 以动词开头，使⽤第⼀⼈称现在时，⽐如 change，⽽不是 changed 或 changes
  • 第⼀个字⺟⼩写
  • 结尾不加句号(.)

message的规范

message 的 body 部分是对本次 mr/commit 的详细描述，说明代码变动的动机，以及与以前⾏为的对⽐。

可以分成多⾏，第 2⾏是空⾏。可以包括的内容有：

• 可以分点详细列出
• 关联 issue
• at 其他相关的同学

相关⼯具⽀持

• commitizen
• validate-commit-msg