程序员应该写出简洁明了的commit log，否则对别人和自己来说就是一种困扰，永远无法从中得知提交人的意图。

IDEA插件推荐

在plugins中搜索Git Commit Template安装即可

安装之后我们正常提交代码时，会多出一个按钮

点击之后，将弹出一个窗口，用来设计提交模板。

插件的介绍界面，说明了提交记录的格式。

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

提交类型Type

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

• feat新功能
• fix修复bug
• docs文档变更
• style格式调整
• refactor重构（非 feat/fix）
• perf性能优化
• test测试相关
• chore构建/工具/依赖等杂项
• build构建系统或外部依赖变更
• revert回滚
• ci持续集成相关

除了这些预设的，团队还可以按照自己的需求，增加新的type。

范围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分钱买商品，目前已经卖出了200单 Closes#2677[skip ci]

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

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