Git 代码提交注释管理规范

简介: Git 代码提交注释管理规范

Git 代码提交注释管理规范

1 注释主体说明

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

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

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

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

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

1.1 type

commit  类型:

  1. feat:  新功能、新特性
  2. fix: 修改 bug
  3. perf: 更改代码,以提高性能(在不影响代码内部行为的前提下,对程序 进行优化)
  4. refactor: 代码重构(重构,在不影响代码内部行为、功能下的代码修 )
  5. docs:  文档修改
  6. style: 代码格式修改,  注意不是 css 修改(多余行删除,代码缩进等)
  7. test: 测试用例新增、修改
  8. build: 影响项目构建或依赖项修改  类如 pom 依赖引入等
  1. revert:  恢复上一次提交
  2. ci:  持续集成相关文件修改(dockerFile 等文件)
  3. chore:  其他修改(不在上述类型中的修改)
  4. release:  发布新版本
  5. 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: 将表格中的查看详情改为详情

相关文章
|
1月前
|
人工智能 缓存 开发工具
结合企业实践来规范你的Git commit(含插件使用指南)
结合企业实践来规范你的Git commit(含插件使用指南)
结合企业实践来规范你的Git commit(含插件使用指南)
|
1月前
|
安全 开发工具 数据安全/隐私保护
《Git 简易速速上手小册》第8章:保护你的代码(2024 最新版)
《Git 简易速速上手小册》第8章:保护你的代码(2024 最新版)
47 1
|
19天前
|
缓存 开发工具 git
windows系统通过git上传代码
windows系统通过git上传代码
|
11天前
|
开发工具 git 开发者
【git merge/rebase】详解合并代码、解决冲突
【git merge/rebase】详解合并代码、解决冲突
29 0
|
1月前
|
存储 开发工具 数据库
git的标签管理
git的标签管理
|
1天前
|
开发工具 git
技巧分享:Git怎么修改已经提交版本的版本注释
技巧分享:Git怎么修改已经提交版本的版本注释
9 4
|
20天前
|
Shell 开发工具 git
git拉去代码报错"Failed to connect to 127.0.0.1 port 31181: Connection refused"
在克隆`https://example.git/`时遇到错误:&quot;fatal: unable to access &#39;https://example.git/&#39;: Failed to connect to 127.0.0.1 port 31181: Connection refused&quot;。原因是Windows上代理设置未正确关闭,影响了Git配置。解决方法是通过git bash运行命令检查并取消代理:`git config --global http.proxy`和`git config --global --unset http.proxy`。
31 1
 git拉去代码报错"Failed to connect to 127.0.0.1 port 31181: Connection refused"
|
5天前
|
Shell 测试技术 网络安全
【GIT】如何在GitHub上向一个开源项目贡献代码?
【GIT】如何在GitHub上向一个开源项目贡献代码?
21 5
|
25天前
|
存储 Linux 项目管理
Git管理与协作指南
Git管理与协作指南
|
6天前
|
开发工具 git
一文教你如何设置git commit模板规范
一文教你如何设置git commit模板规范