git commit 代码提交规范

锐变前端小分队
12,796 阅读5分钟

为什么要制定代码提交规范？

俗话说，国有国法，家有家规，公司有公司的规章制度。那么，小到我们团队，也需要有一定的开发规范，否则将代码混乱，后期查看代码日志log时，五花八门，非常不利于同事阅读新鲜，导致后期维护难度大。

在我们日常团队协作开发中，都要把自己写的功能模块代码提交到github或者gitee上，以便团队人员进行协作开发，那么我们就需要制定一系列的代码规范，促使团队形成统一规范的提交代码风格，提高工作效率。

一般大产都会有一套完善的提交代码规范，特别是一些开源的项目中，都能看到commit message 是非常严谨，非常一致的。

那业界中，公认的commit message 规范是怎么样的呢？

1. commitizen

AngularJS在 github上 的提交记录被业内许多人认可，逐渐被大家引用。

commit 格式规范

<type类型>(<scope 可选作用域>): <subject 描述>
<BLANK LINE>
<body 可选的正文>
<BLANK LINE>
<footer 可选的脚注>

大致主要分为三个部分（每个部分中间用空行分割）：

  • 标题行: 必填, 描述主要修改类型和内容
  • 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
  • 页脚注释: 可以写注释，BUG 号链接 或 Closed Issues
  1. 标题行中的type（必须）：commit 类型，只能填写如下类型：
  • feat: 新功能、新特性
  • fix: 修改 bug
  • perf: 更改代码，性能优化
  • refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
  • docs: 文档修改
  • style: 代码格式修改, 注意不是 css 修改（例如分号修改）
  • test: 测试用例新增、修改
  • build: 影响项目构建或依赖项修改
  • revert: 恢复上一次提交
  • ci: 持续集成相关文件修改
  • chore: 其他修改（不在上述类型中的修改）
  • release: 发布新版本
  • workflow: 工作流相关文件修改
  1. scope（可选）: 用于说明commit 影响的范围, 比如: global, common, route, component, utils, build...
  2. subject: commit 的简短概述，不超过50个字符。
  3. body: commit 具体修改内容, 可以分为多行。
  4. footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接。

例如如下示例：

// 示例1 
fix(global):修复checkbox不能复选的问题 
// 示例2 
fix(common): 修复头部区域logo问题

// 示例1 
feat: 添加资产管理模块

增加资产列表、搜索。

需求No.181 http://xxx.xxx.com/181。

约定式提交规范

内容来自(www.conventionalcommits.org/zh-hans/v1.…)

  • 每个提交都必须使用类型字段前缀，它由一个名词组成，诸如 feat 或 fix ，其后接一个可选的作用域字段，以及一个必要的冒号（英文半角）和空格。
  • 当一个提交为应用或类库实现了新特性时，必须使用 feat 类型。
  • 当一个提交为应用修复了 bug 时，必须使用 fix 类型。
  • 作用域字段可以跟随在类型字段后面。作用域必须是一个描述某部分代码的名词，并用圆括号包围，例如： fix(parser):
  • 描述字段必须紧接在类型/作用域前缀的空格之后。描述指的是对代码变更的简短总结，例如： fix: array parsing issue when multiple spaces were contained in string.
  • 在简短描述之后，可以编写更长的提交正文，为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
  • 在正文结束的一个空行之后，可以编写一行或多行脚注。脚注必须包含关于提交的元信息，例如：关联的合并请求、Reviewer、破坏性变更，每条元信息一行。
  • 破坏性变更必须标示在正文区域最开始处，或脚注区域中某一行的开始。一个破坏性变更必须包含大写的文本 BREAKING CHANGE，后面紧跟冒号和空格。
  • 在 BREAKING CHANGE: 之后必须提供描述，以描述对 API 的变更。例如： BREAKING CHANGE: environment variables now take precedence over config files.
  • 在提交说明中，可以使用 feat 和 fix 之外的类型。
  • 工具的实现必须不区分大小写地解析构成约定式提交的信息单元，只有 BREAKING CHANGE 必须是大写的。
  • 可以在类型/作用域前缀之后，: 之前，附加 ! 字符，以进一步提醒注意破坏性变更。当有 ! 前缀时，正文或脚注内必须包含 BREAKING CHANGE: description

可通过参考资料进行查阅。

2. 通过git pre-commit钩子函数进行自动化提交验证

验证 git commit 规范，主要是通过git的pre-commit钩子函数进行处理的。当然，还需要安装一个辅助的工具来帮助进行验证。

下载安装辅助工具 husky

npm i husky -D

在 package.json 中进行配置 husky

"husky": { 
    "hooks": { 
        "pre-commit": "npm run lint", 
        "commit-msg": "node scripts/verifyCommit.js", 
        "pre-push": "npm test" 
    } 
}

在项目中创建一个 scripts 文件夹，并在文件夹下建立一个 verifyCommit.js 文件，输入如下代码：

const chalk = require('chalk')
const msgPath = process.env.HUSKY_GIT_PARAMS
const msg = require('fs')
   .readFileSync(msgPath, 'utf-8')
   .trim()

const commitRE = /^(feat|fix|docs|style|refactor|perf|test|workflow|build|ci|chore|release|workflow)(\(.+\))?: .{1,50}/

if (!commitRE.test(msg)) {
    console.log(msg)
    console.error(`
        ${chalk.bgRed.white(' ERROR ')} ${chalk.red('不合法的 commit 消息格式。')} \n\n 
        请查看 git commit 提交规范：${chalk.red('git-commit-style.md')}
    `)

    process.exit(1)
}

让我们来了解下上述代码中各个钩子的含义：

  1. "pre-commit": "npm run lint" ，在 git commit 之前先执行 npm run lint 代码规范检查。
  2. "commit-msg": "node scripts/verifyCommit.js"，在 git commit 时执行脚本 verifyCommit.js 验证 commit 消息。如果不符合脚本中定义的格式，将会报错，并提示查看相关的规范文档。
  3. "pre-push": "npm test"，在你执行 git push 将代码推送到远程仓库前，执行 npm test 进行测试。如果测试失败，将不会执行这次推送。

到此，应该大概了解了 git commit 代码提交规范，相信大家有了一份统一的规范，效率会大大的提高。

参考文档： github.com/woai3c/Fron…

www.conventionalcommits.org/zh-hans/v1.…

juejin.cn/post/693087…

avatar
文章
阅读
粉丝