怎样写commit log记录及如何提交有哪些约定

目录
  • 前言
  • 安装插件
  • 提交类型Type
  • 范围scope
  • 其他
    • 主题subject
    • 正文Body
    • 尾部Footer
    • Skip CI
  • End

前言

据说，80%的程序员，不会写commit记录。这个比例在无规范的小公司，比例会更高一些，可以看到这是一个多么普遍的问题。

程序员应该写出简洁明了的commit log，否则对别人和自己来说就是一种困扰。最近代码review多了，总有一股想笑的感觉。就像下图这满屏的ok，永远无法从中得知提交人的意图。

commit log将如何提交？都有哪些约定？其实是有答案的。对于Java程序员，尤其幸福。IDEA有一个非常好用的插件，可以用来辅助你进行代码提交，辅助你进行团队规范建设。接下来，我将带大家看一看它的使用方法。

安装插件

在IDEA的Marketplace中，搜索Git Commit Template，就可以安装这个插件。插件很小，很快就能下载下来。

正常从IDEA提交代码的时候。我们发现多了一个小按钮。

点击之后，将弹出一个窗口。让你去设计提交模板。

这么多信息，真的让人头晕。怪不得程序员们都不喜欢写提交记录。

其实，在插件的安装界面，就已经说明了这个提交记录的格式。

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

从描述中，可以肯容易的看到一个提交记录中，应该包含哪些东西。其中类型最多的，当然是提交类型。

提交类型Type

我们按照插件显示的顺序来说明一下。

feat 功能feature的意思，也是最常用的。当你的功能有变更的时候，都可以采用这种类型的type

fix 当然指的是bug修复

docs 更新了文档，或者更新了注释

style 代码格式调整，比如执行了format、更改了tab显示等

refactor 重构代码。指的是代码结构的调整，比如使用了一些设计模式重新组织了代码

perf 对项目或者模块进行了性能优化。比如一些jvm的参数改动，把stringbuffer改为stringbuilder等

test 这个简单，就是增加了单元测试和自动化相关的代码

build 影响编译的一些更改，比如更改了maven插件、增加了npm的过程等

ci 持续集成方面的更改。现在有些build系统喜欢把ci功能使用yml描述。如有这种更改，建议使用ci

chore 其他改动。比如一些注释修改或者文件清理。不影响src和test代码文件的，都可以放在这里

revert 回滚了一些前面的代码

除了这些预设的，团队还可以按照自己的需求，增加新的type。比如专门处理线上工单，就可以创造一个叫做ticket的类型。

范围scope

scope是范围的意思，主要指的是代码的影响面。scope并没有要求强制，但团队可以按照自己的理解进行设计。通常由技术维度和业务维度两种划分方式。比如按照技术分为：controller、dto、service、dao等。但因为一个功能提交，会涉及到多个scope（都不喜欢非常细粒度的提交），所以按照技术维度分的情况比较少。

按照业务模块进行划分，也是比较不错的选择。比如分为user、order等划分，可以很容易看出是影响用户模块还是order模块。

如果你实在不知道怎么填，那就留空。

其他

主题subject

这个体现的是总结概括能力，没得跑。一句话能够说明主要的提交是什么。subject也是众多git管理工具默认显示的一行。如果你写的标准，那么提交记录看起来就很漂亮很规整。

正文Body

主要填写详细的改动记录。我一般习惯列上1234，但如果你的subject写的非常好，正文可以直接弱化。但如果时间充裕，填写上重要记录的前因后果，需求背景，是一个好的习惯。

尾部Footer

添加一些额外的hook，比如提交记录之后，自动关闭jira的工单（JIRA和gitlab等是可以联动的）。在比如触发一些文档编译或者其他动作。

这部分自定义行也是比较强的。

Skip CI

最后还有一个skip CI选项。一般的ci工具，都可以设置提交代码时自动触发编译。但你可以告诉它忽略本次提交。这可能是因为你提前预判到了一些构建风险，或者就是不想编译。

End

最后，看一个典型的提交记录，有了工具的支持，我们的瞎扯也看得正经起来。

fix(order): 修复了1分钱买汽车的bug
商务反馈可以1分钱买汽车，目前已经卖出了100w量
Closes #2455
[skip ci]

其实，提交的核心是type和subject。一个用来表示它的提交类型，一个用来对提交进行概括性总结，写好了这两点，就能轻轻松松秒杀80%的程序员了。

有了这些基础，从commit log，自动生成change log，就变的非常的容易。配合持续集成平台，自动生成发版的变更记录，也是可行的，这也是为什么团队管理，都在一直强调git的提交规范。因为它确实非常有用。

以上就是怎样写commit log记录及如何提交有哪些约定的详细内容，更多关于commit log记录提交约定的资料请关注我们其它相关文章！

赞 (0)

相关推荐

  • Vuex中this.$store.commit()和this.$store.dispatch()区别说明

    目录 this.$store.commit()和this.$store.dispatch()的区别 commit: 同步操作 dispatch: 异步操作 其他了解 Vuex应用实例this.$store.commit()触发 新建文件夹store,store下 头部公共组件components文件夹下 this.$store.commit()和this.$store.dispatch()的区别 两个方法其实很相似,关键在于一个是同步,一个是异步 commit: 同步操作 this.$store

  • 解决使用commit提交大文件无法推送到远程库问题及git rebase使用详解

    解决这个问题并没有特别的(删除提交历史中某个文件,然后重新push),但是由于开始的使用失误,中间有使用git rebase和git reset命令处理,所以特此记录下 大文件无法push到远程仓库 问题 首先,故事(事故)的起因是这样的. 某次git push(类似测试使用,没有分支)到远程仓库时发生如下无法提交大文件的报错(大文件是一个pdf文件) $ git push Enumerating objects: 204, done. Counting objects: 100% (204/2

  • oracle中commit之后进行数据回滚的方法

    commit之后 第一种: 记住大概的时间,获取前大概时间的数据. select * from Test as of timestamp to_timestamp('2021-12-08 09:30:56','yyyy-mm-dd hh24:mi:ss'); 上面的代码就可以查看你要恢复的时间点的记录,看看是不是有你想要的刚刚提交的DML相关记录. 能看到,剩下的就简单了,可以把现在表中的数据备份到一个临时表,然后把记录插进去原表就行了 不要用truncate删除,不然你就回不去了,到时候你就又

  • 解决linux下redis数据库overcommit_memory问题

    背景 公司的redis有时background save db不成功,通过log发现下面的告警,很可能由它引起的: [13223] 17 Mar 13:18:02.207 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf a

  • 怎样写commit log记录及如何提交有哪些约定

    怎样写commit log记录及如何提交有哪些约定

    目录 前言 安装插件 提交类型Type 范围scope 其他 主题subject 正文Body 尾部Footer Skip CI End 前言 据说,80%的程序员,不会写commit记录.这个比例在无规范的小公司,比例会更高一些,可以看到这是一个多么普遍的问题. 程序员应该写出简洁明了的commit log,否则对别人和自己来说就是一种困扰.最近代码review多了,总有一股想笑的感觉.就像下图这满屏的ok,永远无法从中得知提交人的意图. commit log将如何提交?都有哪些约定?其实是有

  • 解决IDEA GIT记录无法查看提交文件的问题

    解决IDEA GIT记录无法查看提交文件的问题

    问题描述: 某天使用idea,突然发现git提交记录没法查看具体提交的文件了.只能看到提交记录,如下图: 分析可能是修改了控件设置的原因,于是尝试还原设置,重装软件,发现均无效果... 解决方案: 感觉idea开了个玩笑,其实解决方法很简单. 将如图所示的分隔线下拉即可,原来原因是视图遮盖了. 到此这篇关于解决IDEA GIT记录无法查看提交文件的问题的文章就介绍到这了,更多相关IDEA GIT提交文件内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

  • 如何给asp.net core写个中间件记录接口耗时

    如何给asp.net core写个中间件记录接口耗时

    Intro 写接口的难免会遇到别人说接口比较慢,到底慢多少,一个接口服务器处理究竟花了多长时间,如果能有具体的数字来记录每个接口耗时多少,别人再说接口慢的时候看一下接口耗时统计,如果几毫秒就处理完了,对不起这锅我不背. 中间件实现 asp.net core 的运行是一个又一个的中间件来完成的,因此我们只需要定义自己的中间件,记录请求开始处理前的时间和处理结束后的时间,这里的中间件把请求的耗时输出到日志里了,你也可以根据需要输出到响应头或其他地方. public static class Perf

  • MySQL组提交group commit详解

    MySQL组提交group commit详解

    目录 引 言 前提: 背景说明: 图解: Flush 阶段 (图中第一个渡口) Sync 阶段 (图中第二个渡口) Commit 阶段 (图中第三个渡口) 缺陷分析: 引 言 前提: 以下讨论的前提 是设置MySQL的crash safe相关参数为双1: sync_binlog=1 innodb_flush_log_at_trx_commit=1 背景说明: WAL机制 (Write Ahead Log)定义: WAL指的是对数据文件进行修改前,必须将修改先记录日志.MySQL为了保证ACID中

  • Git远程删除某个历史提交记录方法详解

    Git远程删除某个历史提交记录方法详解

    目录 引言 一.删除最后一次提交 二.删除指定commit提交(非最后一次提交) 引言 在开发中经常会遇到在本地测试的代码或者隐私信息,一不小心提交到了远程仓库,即便立即删除了再提交,但是上次的提交记录在远程依旧可以查看. 特别是像账号密码.key文件这种,很可能造成隐私泄露. 分两种情况: 一.删除最后一次提交 这种情况比较简单,主要操作分两步: 第一步:回滚上一次提交 git reset --hard HEAD^ 第二步:强制提交本地代码 git push origin master -f

  • c#程序定期把内存信息记录到log日志示例

    设立一个定时器tmrMonitor,该定时器会在程序运行时不断把程序的占用内存和占用线程数写到LOG\MEM目录下.我设置的定时器间隔是3000毫秒,记录后的信息可以用来分析一段时间内程序的运行状况,比如内存泄漏问题. 复制代码 代码如下: /// <summary>/// Timer组件tmrMonitor的Tick事件/// </summary>/// <param name="sender"></param>/// <para

  • MySQL系列之redo log、undo log和binlog详解

    MySQL系列之redo log、undo log和binlog详解

    事务的实现 redo log保证事务的持久性,undo log用来帮助事务回滚及MVCC的功能. InnoDB存储引擎体系结构 redo log Write Ahead Log策略 事务提交时,先写重做日志再修改页:当由于发生宕机而导致数据丢失时,就可以通过重做日志来完成数据的恢复. InnoDB首先将重做日志信息先放到重做日志缓存 按一定频率刷新到重做日志文件 重做日志文件: 在默认情况,InnoDB存储引擎的数据目录下会有两个名为ib_logfile1和ib_logfile2的文件.每个In

  • MySQL中的redo log和undo log日志详解

    MySQL中的redo log和undo log日志详解

    MySQL日志系统中最重要的日志为重做日志redo log和归档日志bin log,后者为MySQL Server层的日志,前者为InnoDB存储引擎层的日志. 1 重做日志redo log 1.1 什么是redo log redo log用于保证事务的持久性,即ACID中的D. 持久性:指一个事务一旦被提交,它对数据库中数据的改变就是永久性的,接下来即使数据库发生故障也不应该对其有任何影响. redo log有两种类型,分别为物理重做日志和逻辑重做日志.在InnoDB中redo log大多数情

  • Mysql数据库面试必备之三大log介绍

    Mysql数据库面试必备之三大log介绍

    目录 一.redo log 重做日志(MySQL 存储引擎 InnoDB 的事务日志) 二.undo log 回滚日志(MySQL 存储引擎 InnoDB 的事务日志) 三.bin log 归档日志(数据库 Server 层二进制逻辑日志.和什么引擎无关) 快,开篇大伙先思考一个问题,MySQL 是怎么保证数据不丢失的呢? 其实要保证数据不丢失,说白了要具有下面两种能力: (1)能恢复到任何时间点的状态: (2)能保证 MySQL 在任何时间段突然宕机重启,已提交的数据不会丢失,未提交完整的数据

  • mysql中redo log和 binlog的区别

    mysql中redo log和 binlog的区别

    想跟大家聊聊关于 mysql 中的两个小的知识点:redo log 和 binlog . redo log :InnoDB 存储引擎层方面的日志,所以如果你使用的存储引擎不是 InnoDB 的话,那就根本谈不上 redo log. binlog : MySQL Server 层记录的日志,所以不管是用的什么存储引擎,只要是 MySQL 都是会有 binlog 的存在,在做 MySQL 主从复制的时候,利用的就是 binlog. 接下来,我们就详细来看看它们都分别做了啥? redo log 为什么

随机推荐