Git提交日志规范指南
在软件开发流程中，Git已经成为版本控制的事实标准。每次提交代码都需要填写commit message，否则不允许提交。然而，在日常开发中，我们经常会看到各种各样模糊不清的提交信息，如“fix bug”、“更新代码”、“修改问题”等。这些不规范的commit message充斥在git history中，导致后续维护人员无法快速定位问题，有时甚至连提交者自己都不记得某次提交的目的。因此，我们需要一套统一的规范来管理和约束commit message。 规范概述 目前业界最知名的规范是Angular团队的commit message规范，它结构清晰、易于实施，已被广泛应用于开源项目和商业项目中。同时，许多IDE（如IntelliJ IDEA）也提供了相应的插件（如Git Commit Template）来辅助开发者遵循这一规范。 本文将以Angular规范为基础，详细介绍一套通用的Git commit message规范，并提供具体的操作示例。 Commit Message整体结构 规范的commit message包含三个部分：Header、Body和Footer。其格式如下： <header> <BLANK LINE> <body> <BLANK LINE> <footer> 重要说明： Header是必需的，包含type、scope和summary三个子元素 Body是必需的，用于详细描述提交内容 Footer是可选的，用于记录不兼容变更或关闭issue 关键规则：Header和Body之间必须有一个空行分隔，这是许多Git工具正确解析提交信息的前提。 整体结构示例 feat(用户认证): 增加短信验证码登录功能 为了提升用户登录体验，增加了通过手机号接收验证码进行登录的方式。 - 集成阿里云短信服务 - 新增验证码生成与校验逻辑 - 更新登录页面UI Closes #245 Header详解 Header是commit message的“标题”，格式为： <type>(<scope>): <summary> 其中，type和summary为必填项，scope为可选项。 Type：提交类别 Type用于说明本次提交的类别，必须使用以下标准化标识之一： Type 说明 使用场景 feat 新功能 新增用户可见的功能特性 fix 修复bug 修复线上或测试环境发现的缺陷 docs 文档更新 仅修改文档，不涉及代码变更 style 代码格式 不影响代码运行的格式调整（空格、缩进、分号等） refactor 代码重构 既不是新增功能，也不是修复bug的代码结构调整 perf 性能优化 提升系统性能或用户体验的代码变更 test 测试相关 新增或修改测试用例 chore 构建/工具变动 构建流程、依赖管理、辅助工具等变更 revert 回滚提交 撤销之前的某次提交 Type使用示例：...