阅读 1285

关于 Git 提交规范

@关于 Git 提交规范

create by db on 2021-1-25 16:34:46
Recently revised in 2021-1-25 19:34:56

闲时要有吃紧的心思,忙时要有悠闲的趣味

目录

前言

返回目录

  无规矩不成方圆,编程也一样。

  如果你有一个项目,从始至终都是自己写,那么你想怎么写都可以,没有人可以干预你。可是如果在团队协作中,大家都张扬个性,那么代码将会是一团糟,好好的项目就被糟践了。不管是开发还是日后维护,都将是灾难。

  这时候,有人提出了何不统一标准,大家都按照这个标准来。于是 ESLint,JSHint 等代码工具如雨后春笋般涌现,成为了项目构建的必备良品。

  Git Commit 规范可能并没有那么夸张,但如果你在版本回退的时候看到一大段糟心的提交信息(更可怕的是没有提交信息),恐怕会懊恼不已吧。

正文

返回目录

提交规范的作用

  很多时候,看提交历史的人跟提交代码的人都不是同一个人,当别人阅读你的提交历史时,他很可能是不知道具体代码细节的,你如何在最短的时间内让他一眼知道每次提交的意义:

  • 每次提交影响的具体范围?
  • 这个 bug 在哪次提交中被修复了?
  • 这个新功能是在哪次提交中增加的?
  • 修改是否向下兼容?
  • 是否回滚了代码?
  • 是否只是修改了文档、调整了代码格式?
  • 是否修改了测试、是否进行了重构?
  • 是否对代码进行了性能优化?

提交规范的格式

  用什么规范?

  现在比较流行的方案是约定式提交规范(Conventional Commits),它受到了 Angular 提交准则的启发,并在很大程度上以其为依据。

约定式提交规范 是一种基于提交消息的轻量级约定。 它提供了一组用于创建清晰的提交历史的简单规则;这使得编写基于规范的自动化工具变得更容易。这个约定与 SemVer( 语义化版本(Semantic Versioning)规范 的一个实现,目前是由 npm 的团队维护,实现了版本和版本范围的解析、计算、比较。) 相吻合,在提交信息中描述新特性、bug 修复和破坏性变更。

  每个提交消息都由一个header(标题)、一个body(正文)和一个或多个footer(s)(页脚)组成。

  它的 message 格式如下:

< type > [optional scope]: < description > // header
// 空一行
[optional < body > ]
// 空一行
[optional < footer(s) > ]
复制代码

举个简单的例子:

feat(config): 允许 config 对象直接从其他 config 继承

BREAKING CHANGE: 在 config 对象中增加 `extends` 字段,用于从其他继承 config

close issue #23
复制代码

当然我们也可以写的简洁一些

feat: 允许 config 对象直接从其他 config 继承
复制代码

注:

  • 在命令行里 git commit 时,如果你想进行多行 commit 编辑,可以通过 git commit -a 进入编辑界面;如果是单行,可以直接 git commit -m 'COMMIT MESSAGE' 完成提交。

格式讲解

一. header(标题 必填)

  header 部分只有一行,包括三个字段: type (必需)、 scope (可选)和 description (必需)。

  其中最重要的就是 header 这部分,至于 <body><footer(s)> 可省略

例如:

feat:新增表格组件
复制代码

1. type(修改类型 必填)

  type 为必填项,用于指定 commit 的类型,约定了 featfix 两个主要 type,以及 docsstylebuildrefactorrevert 五个特殊 type,其余 type 暂不使用。(参考人人贷大前端技术中心

# 主要type
feat:     增加新功能
fix:      修复bug

# 特殊type
docs:     只改动了文档相关的内容
style:    不影响代码含义的改动,例如去掉空格、改变缩进、增删分号
build:    构造工具的或者外部依赖的改动,例如webpack,npm
refactor: 代码重构时使用
revert:   执行git revert打印的message

# 暂不使用type
test:     添加测试或者修改现有测试
perf:     提高性能的改动
ci:       与CI(持续集成服务)有关的改动
chore:    不修改src或者test的其余修改,例如构建过程或辅助工具的变动
复制代码

注:

  • 当一次改动包括主要 type 与特殊 type 时,统一采用主要 type。

2. scope(影响范围 选填)

  可选项,用来说明此次修改的影响范围,格式为项目名/模块名,可以是一个文件的地址,如 /lib/utils ;也可以是某个功能点 parser,不建议超过两个单词

如:

.all       //表示影响面大 ,如修改了网络框架 会对真个程序产生影响
.loation   //表示影响小,某个小小的功能
.module    //表示会影响某个模块 如登录模块、首页模块 、用户管理模块等等
复制代码

注:

  • 如果一次 commit 修改多个模块,建议拆分成多次 commit,以便更好追踪和维护。

3. description(描述 必填)

  必填项,是 commit 目的的简短描述,不超过 50 个字符。

规范如下:

  • 以动词开头,使用第一人称现在时,比如 change,而不是 changed 或 changes
  • 第一个字母小写
  • 结尾不加句号(.)

二. body(正文 选填)

  body是对标题的补充,但它不是必须的。

  body 主要描述改动之前的情况及修改动机,对于小的修改不作要求,一般不用写。但是重大需求、更新等必须添加 body 来作说明。

三. footer(s)(页脚 选填)

  可选项,放置备注啥的,一般不用写。它经常用来引用本次提交解决的GitHub Issue。 如果是 bug ,可以把 bug ID放。

相关工具推荐

Vscode插件(Git-commit-plugin For Vscode)

  这个一个VSCODE插件的,对于喜欢使用Vscode编码的朋友来说用起来很方便的。

  使用详情请参考 Git-commit-plugin For Vscode 一款自动生成规范git提交信息的插件 | segmentfault - redjue

commitizen

  这个一款基于 Node 的交互式约束命令工具,适合喜欢使用命令行的小伙伴。

  使用详情请参考 Git commit message 规范 | 掘金 - 人人贷大前端技术中心

git 设置模板

  对于喜欢使用 如sourceTree一样有着界面的git工具的同学,就可以采用 git 配置模板的方式。

  使用详情请参考 老鸟都应该注意的git 提交规范| 博客园 - Four two

总结

返回目录

  实际中工作中,我们不一定要采用这种规则,但是可以借鉴它,然后自己那边再根据实际情况变动。毕竟,适合的才是最好的。

  另外关于什么时候提交,尽可能是完成一个新的功能或者是优化某个功能,解决某个 bug 等就提交(commit),避免一次提交很多更改,那样不好回溯。

人生苦短,遵守规范。

  路漫漫其修远兮,与诸君共勉。

参考文档:

后记:Hello 小伙伴们,如果觉得本文还不错,记得点个赞或者给个 star,你们的赞和 star 是我编写更多更丰富文章的动力!GitHub 地址

文档协议

db 的文档库db 采用 知识共享 署名-非商业性使用-相同方式共享 4.0 国际 许可协议进行许可。
基于github.com/danygitgit上的作品创作。
本许可协议授权之外的使用权限可以从 creativecommons.org/licenses/by… 处获得。

文章分类
前端
文章标签