Git 代码提交注释管理规范

正在走向自律

于 2024-03-14 11:09:02 发布

阅读量1.1k

点赞数 32

分类专栏：开发工具开发规范文章标签： git intellij-idea

本文链接：https://blog.csdn.net/beautifulmemory/article/details/136701905

版权

开发工具同时被 2 个专栏收录

16 篇文章 0 订阅

订阅专栏

开发规范

2 篇文章 0 订阅

订阅专栏

Git 代码提交注释管理规范

1 注释主体说明

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

<footer>

大致分为三个部分(使用空行分割):

1. 标题行: 必填, 描述主要修改类型和内容

2. 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等

3. 页脚注释: 放 Breaking Changes 或 Closed Issues

1.1 type

commit 的类型：

feat: 新功能、新特性
fix: 修改 bug
perf: 更改代码，以提高性能(在不影响代码内部行为的前提下，对程序性能进行优化)
refactor: 代码重构(重构，在不影响代码内部行为、功能下的代码修改)
docs: 文档修改
style: 代码格式修改, 注意不是 css 修改(多余行删除，代码缩进等)
test: 测试用例新增、修改
build: 影响项目构建或依赖项修改类如 pom 依赖引入等
revert: 恢复上一次提交
ci: 持续集成相关文件修改(dockerFile 等文件)
chore: 其他修改(不在上述类型中的修改)
release: 发布新版本
workflow: 工作流相关文件修改

1.2 scope

commit 影响的范围, 比如: route, component, utils, build,一般填写当前修改目录或者功能模块的名称，例如修改公共包公共包，影响范围就是全局。

1.3 subject

commit 的概述

1.4 body

commit 具体修改内容, 可以分为多行.

1.5 footer

一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.

2 约定式提交规范

2.1 使用说明

• 每个提交都必须使用类型字段前缀，它由一个名词组成，诸如 feat 或 fix ，其后接一个可选的作用域字段，以及一个必要的冒号 (英文半角)和空格。

• 当一个提交为应用或类库实现了新特性时，必须使用 feat 类型。

• 当一个提交为应用修复了 bug 时，必须使用 fix 类型。

• 作用域字段可以跟随在类型字段后面。作用域必须是一个描述某部分代码的名词，并用圆括号或者中括号包围，例如： fix(parser):/ 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.2 使用示例

2.2.1 fix 示例

如果修复的这个 BUG 只影响当前修改的文件，可不加范围。如果影响的范围比较大，要加上范围描述。

例如这次 BUG 修复影响到全局，可以加个 global。如果影响的是某个目录或

某个功能，可以加上该目录的路径，或者对应的功能名称。建议使用中文

// 示例 1
Fix[lobal]:修复 checkbox 不能复选的问题
// 示例 2 下面圆括号里的 common 为通用管理的名称
fix(common): 修复字体过小的 BUG，将通用管理下所有页面的默认字体大小修改为 14px
// 示例 3
fix: value.length -> values.length

2.2.2 feat 示例 (建议使用)

feat【登录模块】 : 添加网站主页静态页面
这是一个示例， 假设对点检任务静态页面进行了一些描述。
这里是备注，可以是放 BUG 链接或者一些重要性的东西。

2.2.3 chore 示例

chore 的中文翻译为日常事务、例行工作，顾名思义，即不在其他 commit 类型中的修改，都可以用 chore 表示。

chore: 将表格中的查看详情改为详情

正在走向自律

关注

32
点赞
踩
23

收藏

觉得还不错? 一键收藏
1
评论
Git 代码提交注释管理规范

大致分为三个部分(使用空行分割):1. 标题行: 必填, 描述主要修改类型和内容2. 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等3. 页脚注释: 放 BreakingChanges或 ClosedIssues
复制链接

扫一扫