[Git CLion] 规范Commit格式

规范Commit格式

Jenkins根据对比当次构建和上次构建的Commit信息来生成ChangeLog,但因为我们目前的提交不够规范,经常有类似"#","update"这列的提交,无法提供给PM有效的更新记录,所以建议大家尽量规范Commit格式。

Conventional Commits

目前推荐大家是有这套规范,如果大家有更好的可以推荐使用,官网链接如下:
Conventional Commits

官网介绍的很详细,要求也比较多,有一些我们可能也用不到,而且也会增加学习难度,所以我这边整理了一下适合我们的规范,比较简单,但应该够用,

格式

原文

    [optional scope]: 

    [optional body]

    [optional footer(s)]

译文

    [可选 范围]: 

    [可选 正文]

    [可选 脚注]

格式说明

示例如下:
[Git CLion] 规范Commit格式插图

type

  1. fix: 类型fix 的提交表示在代码库中修复了一个bug。
  2. feat: 类型feat 的提交表示在代码库中新增了一个功能。
  3. perf:类型 为 perf 的提交表示在代码库中做了性能优化。
  4. style:类型 为 style 的提交表示在不影响代码含义的变化(空白,格式化,缺少分号等)。
  5. docs:类型 为 docs 的提交表示仅更新文档。
  6. refactor:类型 为 refactor 的提交表示重构,不修复 bug 且不添加功能。

示例属于新增功能,所以使用了feat

optional scope

范围必须是一个描述某部分代码的名词,并用圆括号包围。
示例只影响到BlankSystem,所以scope写的是这次只针对BlankSystem。

description

描述字段必须直接跟在(范围) 前缀的冒号和空格之后。 描述指的是对代码变更的简短总结。
示例总结主要是为了能让非开发(PM)看懂,方便写release note,所以尽量用大家都知道的描述。

optional body

在简短描述之后,可以编写较长的提交正文,为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
示例简短描述是为了给非开发(PM)查看,正文是尽量让研发内部直接看懂,这里建议大家尽量写的清楚详细。

optional footer(s)

如果和每个jira相关,附带就可以。

CLion示例

1. 下载插件Conventional Commit

[Git CLion] 规范Commit格式插图1

2. Commit窗口打钩需要push的文件,然后邮件选择Commit Files...

3. Commit窗口左下角Amend左键红圈

[Git CLion] 规范Commit格式插图2

4. Build Commit Message填好更新内容,然后会自动更新到Amend

[Git CLion] 规范Commit格式插图3
[Git CLion] 规范Commit格式插图4

5. Amend窗口点击Commit and Push...,然后在Push Commits to xxxx的窗口push

[Git CLion] 规范Commit格式插图5

6. 最后在Bitbucket上可以看到提交内容

[Git CLion] 规范Commit格式插图6

文章来源于互联网:[Git CLion] 规范Commit格式

THE END
分享
二维码