不会写Commit记录?

• rf 对项目或者模块进行了性能优化。比如一些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工具，都可以设置提交代码时自动触发编译。但你可以告诉它忽略本次提交。这可能是因为你提前预判到了一些构建风险

（编辑：三明站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!