一个专门做恐怖片的网站,注册公司网站怎么收费,如何制作自己的视频网站,商业网站建设所用软件B站|公众号#xff1a;啥都会一点的研究生
写在前面
在很长的一段时间中#xff0c;使用git commit都是随心所欲#xff0c;log肥肠简洁#xff0c;随着代码的迭代#xff0c;当时有多偷懒#xff0c;返过头查看git日志就有多懊悔#xff0c;就和写代码不写doc string…
B站|公众号啥都会一点的研究生
写在前面
在很长的一段时间中使用git commit都是随心所欲log肥肠简洁随着代码的迭代当时有多偷懒返过头查看git日志就有多懊悔就和写代码不写doc string或写的很简单一样将浪费无数时间重新浏览
其实git commit格式是有约定的以下对一些常用进行说明一起看看吧
正文
提交commit的结构如下
type[optional scope]: description[optional body][optional footer(s)]type
首先是type必填项能直观的向向各使用者传达进行了哪类型的更新一般使用较多的为
fix用于表明修复了代码库中的bugfeat在代码库中新增了功能
此外还有一些其他类型
perf在不影响代码内部行为的情况下进行了优化提升性能refactor代码重构docs只修改了文档类型的内容style不影响代码含义的修改如删除空格等test测试用例的新增或修改build项目构建或依赖进行更新revert一种特殊情况如果当前commit用于撤销以前的commit则必须用该type后面跟着被撤销commit的Header。ci与 CI持续集成服务有关的改动如GitLab CIchore其他修改
很多人不知道的是这些type后可以搭配!用于向使用者表明本次更新较为重要如feat!: description
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 configsBREAKING 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 6BREAKING CHANGE: use JavaScript features not available in Node 6.提交没有正文的消息
docs: correct spelling of CHANGELOG提交具有多段落body和多个footer的消息
fix: prevent racing of requestsIntroduce 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: 并且提交描述将用于描述破坏性更改
以上就是本期的全部内容期待点赞在看我是啥都生下次再见
