Git 提交日志格式规约

文章目录

1. 1. git规范说明
2. 2. Commit 格式
3. 3. 前置条件
4. 4. 示例说明

规范Git 提交日志内容及格式对说明代码内容和后记追溯问题有很多的帮助, 本文从工作中总结相关的经验成文,

git规范说明

为什么要对 Git 提交日志的格式进行规约约束？

1. 最重要的原因：便于人类程序员对提交历史进行追溯，了解发生了什么情况。因此像「update」甚至于「u」这样的 log，都是不合格的写法，想必诸如此类的 log 已经被大家咒骂过一遍遍。
2. 另外，一旦约束了提交日志，意味着我们将慎重地进行每一次提交，不能再一股脑儿地把各种各样的改动都放到一个提交里面，这样一来，整个代码改动的历史也将更加清晰。
3. 想得更远一点，格式化的 log 才可能用于自动化输出 changelog。

对Git提交日志进行格式约束是否带来较高的执行成本？

1. 所谓仓廪实而知礼节，随着大型共建项目 / 开源项目的增多，必然要用更专业化的态度去面对。规约化的 Git log 正是其中一环。
2. 最后，如果实在无法完美遵循日志规约，最最重要的原则是：至少要保证在整个项目中 log 格式的一致性！不要做一个朝秦暮楚的人

Commit 格式

Commit Message = {type}:{Jira号},{subject}

type, 必须

提交类型 type 用来描述一次提交行为的改动方向。

type 的可选值如下。注意：Git log 的 type 和 changelog 的 type 存在紧密联系；然而它们两者之间并非一一对应，比如在 changelog 中一般不会指出文档 docs 或测试用例 test 等方面发生的变化。

• feat: 新增功能。（task功能提交）
• fix: 修复 bug。(bug修复)
• docs: 文档相关的改动。(在线文档，说明文档，注释内容)
• style: 对代码的格式化改动，代码逻辑并未产生任何变化。(样式文件修改)
• test: 新增或修改测试用例。
• refactor: 重构代码或其他优化举措。
• chore: 项目工程方面的改动，代码逻辑并未产生任何变化。

Jira号

• task/已有bug提交，必须携带Jira号，提交纪录，jira上都会有log统计
• 自我修复，优化内容，如果没有对应的Jira可以省略，但subject必须写清楚修改内容

subject

• 主题 subject 用来概括一次提交行为囊括的内容（注意不是jira的标题）
• 简要明了的描述下修改的内容，方便代码review，和后期自己查找纪录
• 原则上，通过描述就能清楚的知道，修改的内容
• 默认使用中文

前置条件

• 单一原则，一个commit就只做一个内容，不要提交和主题无关的内容，无论这次提交的内容有多简单
• 没有task, 自己创建并关联到对应的Story上，代码通过review，关闭相关task/bug
• 不要task,bug混提交
• 不要多个task,bug合并提交
• 如果在提交feat/fix, 对这部分提交相关的代码做了重构/优化，可以合并到feat/fix提交中
• 提交后立即找相关Review人review代码，如有有打回，继续追加提交修复内容了，建议不要多个commit一起提交

示例说明

• feat：JIRA-1224，告警信息列表页面以及告警信息详情页面，日期时间的显示调整
• fix：JIRA-1215，修复系统镜像、自定义镜像，修改镜像名称，操作系统和系统盘大小不会相应改变
• style：修复列表头部按钮，左右间距
• docs: 更新在线文档
• chore: 调整开发环境地址
• refactor：优化云主机创建页面代码逻辑