Git Commit 提交规范

背景

Git每次提交代码都需要写commit message，否则就不允许提交。一般来说，commit message应该清晰明了，说明本次提交的目的，具体做了什么操作。但是在日常开发中，大家的commit message千奇百怪，中英文混合使用、fix bug等各种笼统的message司空见怪，这就导致后续代码维护成本特别大，有时自己都不知道自己的fix bug修改的是什么问题。基于以上这些问题，我们希望通过定制 git commit 规范，让规范更好的服务于质量，提高大家的研发效率。

规范建设

目前Angular规范是使用最广的写法，比较合理和系统化，并且有配套的工具（IDEA就有插件支持这种写法）。

commit message格式

Commit message 都包括三个部分：header，body 和 footer。

header 是必需的，body 和 footer 可以省略。

不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。

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

type 更改类型(必须)

用于说明git commit的类别，只允许使用下面的标识。

  1. feat：新功能（feature）。

  2. fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。

    1. fix：产生diff并自动修复此问题。适合于一次提交直接修复问题

    2. to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix

  3. docs：文档（documentation）。

  4. style：格式（不影响代码运行的变动）。

  5. refactor：重构（即不是新增功能，也不是修改bug的代码变动）。

  6. perf：优化相关，比如提升性能、体验。

  7. test：增加测试。

  8. build: 构建依赖更改

  9. ci: 更改 CI 配置文件或者脚本

  10. chore：更改构建流程、或者增加依赖库、工具等

  11. revert：回滚到上一个版本。

  12. merge：代码合并。

  13. sync：同步主线或分支的Bug。

scope 此次变更范围(可选)

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。如果你的修改影响了不止一个scope，你可以使用*代替。

scope 主要指的是代码的影响面。scope并没有要求强制，但团队可以按照自己的理解进行设计。通常由技术维度和业务维度两种划分方式。比如按照技术分为：controller、dto、service、dao等。但因为一个功能提交，会涉及到多个scope（都不喜欢非常细粒度的提交），所以按照技术维度分的情况比较少。

按照业务模块进行划分，也是比较不错的选择。比如分为user、order等划分，可以很容易看出是影响用户模块还是order模块

subject 简短描述(必须)

subject是commit目的的简短描述，不超过50个字符。技术文档的大标题、功能的概述

建议使用中文（感觉中国人用中文描述问题能更清楚一些）。

  • 结尾不加句号或其他标点符号。

  • 根据以上规范git commit message将是如下的格式：

fix(order): 修复了1分钱购买套餐的bug

测试反馈可以1分钱买套餐，目前已经卖出了200单

Closes #2677

[skip ci]

body (可选)

body 详细描述

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

  • 第2行是空行

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

changes 重大变更(可选)

即不兼容修改，指的是本次提交修改了不兼容之前版本的API或者环境变量

所有不兼容修改都必须在页脚中作为中断更改块提到，以BREAKING CHANGE:开头，后跟一个空格或者两个换行符，其余的信息就是对此次修改的描述，修改的理由和修改注释

BREAKING CHANGE: isolate scope bindings definition has changed and
    the inject option for the directive controller injection was removed.

    To migrate the code follow the example below:

    Before:

    。。。
    。。。

    After:

    。。。
    。。。

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

closes 关闭问题(可选)

如果本次提交目的是修改issue的话，需要在页脚引用该issue

以关键字Closes开头，比如

Closes #234

如果修改了多个bug，以逗号隔开

Closes #123, #245, #992

skipCi(可选)

CI 全称 Continuous Integration，名为持续集成，传统的 CI 含义指的是代码仓库只要有代码变更（或者说有人想推代码入库），就会自动执行预先设计好的检查、防护流程，运行一系列构建、测试、部署等流程，并最终告知每一步的运行结果，确保人提交上来的代码没有问题后，才有机会将新代码合并到主干分支，而主干分支无论何时都一定是正确可运行的高质量版本，可以随时交付客户使用。

skip CI选项，跳过 CI 。一般的 CI 工具，都可以设置提交代码时自动触发编译。但你可以告诉它忽略本次提交。这可能是因为你提前预判到了一些构建风险，或者就是不想编译。

Revert

还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert: 开头，后面跟着被撤销 Commit 的 Header。

revert: feat(pencil): add 'graphiteWidth' option

This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

规范 Git 提交信息工具

上面的内容比较多，记下来比较繁琐的，特别是有时候我们很难记住所有的 type 类型，IDEA 现在有一个插件，就是用来规范 git 提交模板的。

在 IDEA 的插件市场中安装 git commit message helper，直接搜索安装，然后重启 IDEA 即可。

在 VScode 可以安装插件 Git-commit-plugin For Vscode

案例：

点击提交后结果：

feat(dao): 加类

加了xxxx
添加字段xxxx
删除xxxx

BREAKING CHANGE: 添加xxxx2.0
删除xxx1.0

Closes 1257

[skip ci]

git commit 规范指南

Angular提交信息规范 - Git Guide

posted @ 2024-07-09 15:45  KMP  阅读(219)  评论(0)  编辑  收藏  举报