Git commit记录规范

程序员应该写出简洁明了的commit log否则对别人和自己来说就是一种困扰永远无法从中得知提交人的意图。IDEA插件推荐在plugins中搜索Git Commit Template安装即可安装之后我们正常提交代码时会多出一个按钮点击之后将弹出一个窗口用来设计提交模板。插件的介绍界面说明了提交记录的格式。从描述中可以很容易的看到一个提交记录中应该包含哪些东西。其中类型最多的就是是提交类型。提交类型Type我们按照插件显示的顺序来说明一下。feat新功能fix修复bugdocs文档变更style格式调整refactor重构非 feat/fixperf性能优化test测试相关chore构建/工具/依赖等杂项build构建系统或外部依赖变更revert回滚ci持续集成相关除了这些预设的团队还可以按照自己的需求增加新的type。范围scopescope是范围的意思主要指的是代码的影响面。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的提交规范。因为它确实非常有用。