别再乱写git commit了

B站|公众号：啥都会一点的研究生

写在前面

在很长的一段时间中，使用git commit都是随心所欲，log肥肠简洁，随着代码的迭代，当时有多偷懒，返过头查看git日志就有多懊悔，就和写代码不写doc string或写的很简单一样，将浪费无数时间重新浏览

其实，git commit格式是有约定的，以下对一些常用进行说明，一起看看吧

正文

提交commit的结构如下

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

type

首先是type，必填项，能直观的向向各使用者传达进行了哪类型的更新，一般使用较多的为

• fix：用于表明修复了代码库中的bug
• feat：在代码库中新增了功能

此外，还有一些其他类型

• perf：在不影响代码内部行为的情况下进行了优化，提升性能
• refactor：代码重构
• docs：只修改了文档类型的内容
• style：不影响代码含义的修改，如删除空格等
• test：测试用例的新增或修改
• build：项目构建或依赖进行更新
• revert：一种特殊情况，如果当前commit用于撤销以前的commit，则必须用该type，后面跟着被撤销commit的Header。
• ci：与 CI（持续集成服务）有关的改动，如GitLab CI
• chore：其他修改

很多人不知道的是这些type后可以搭配!用于向使用者表明本次更新较为重要，如feat!:

scope

再是scope，选填，用于阐明本次commit 影响的范围，如与数据预处理相关、某模块功能相关等

description

必填，顾名思义就是对本次的提交做个简短概述

• 以动词开头，使用现在时如fix，而不是fixed
• 第一个字母小写
• 结尾不加句号（.）

body

选填，详细描述本次的commit，一般小的修改在上面description即可描述清楚，而重大更新尽量把body写的详尽，可分行

footer

一般只涉及BREAKING CHANGE和ISSUE相关

• BREAKING CHANGE：比如涉及重大变更则本部分为必填项，类似版本升级、接口变更等
• ISSUE相关：如当前 commit 针对某个issue，可进行引用/关闭

以下参考www.conventionalcommits.org

例子

• 带有description和 breaking change footer的commit

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

• 使用!提交消息以引起对重大更改的注意

feat!: send an email to the customer when a product is shipped

• 提交带有范围和!的消息

feat(api)!: send an email to the customer when a product is shipped

• 提交带有!和BREAKING CHANGE footer的消息

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

• 提交没有正文的消息

docs: correct spelling of CHANGELOG

• 提交具有多段落body和多个footer的消息

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

约定规范

• commit必须以type为前缀，类型由名词（例如feat表示新功能，fix表示修复等）组成，后面是可选的范围（scope），可选的感叹号（!），和必需的冒号（英文半角）和空格

• commit后可以提供范围（scope），必须由括号括起的描述代码库部分的名词组成，例如fix(parser)

• 冒号和类型/范围前缀之后必须立即跟着描述（description），描述是代码更改的简短摘要

• 在简短描述之后，可以提供较长的正文（body）描述，提供有关代码更改的详细上下文信息。正文必须在description之后的一个空行处开始。

• body是自由格式的，可以由任意数量的用换行符分隔的段落组成

• 在正文结束的一个空行之后，可以编写一行或多行脚注（footer）。脚注必须包含关于提交的元信息，例如：关联的合并请求、ISSUE相关、重大变更，每条元信息一行

• 破坏性变更必须标示在正文区域最开始处，或脚注区域中某一行的开始

• 如果将破坏性变更写在脚注中，必须包含大写文本BREAKING CHANGE，后面紧跟冒号、空格和相关描述，例如BREAKING CHANGE: environment variables now take precedence over config files.

• 如果破坏性变更写在正文，必须在冒号前加上!，如果使用!则可以从脚注部分省略BREAKING CHANGE: ，并且提交描述将用于描述破坏性更改

以上就是本期的全部内容，期待点赞在看，我是啥都生，下次再见