Git提交规范与IDEA插件实践
前言
缘由
没想到使用了多年Git，竟发现提交描述也有规范。工作中观察到同事的Git提交描述风格统一，经研究后发现许多大厂和开源项目都遵循特定的Git提交规范。本文旨在总结并分享这些规范，帮助团队提升提交信息的可读性和可维护性。
实例展示
规范Git提交记录
不规范Git提交记录
分析
在团队开发中，使用Git管理代码时，若提交信息（commit message）没有统一规范，随着项目复杂度和团队成员增加，会严重影响代码的阅读、管理和维护。通过上图对比可见，规范的提交记录清晰明了，便于快速理解提交目的。因此，制定并执行统一的提交规范至关重要。
主要目标
- IDEA Git描述规范插件：介绍辅助工具的使用。
- Git提交描述格式规范：详解标准提交信息的结构。
- 实例Git提交描述解析：通过案例演示规范提交。
正文
目标分析
1. IDEA Git描述规范插件
【Git Commit Message Helper】介绍
一个帮助您标准化提交内容的IDEA插件。
插件安装步骤
- 点击 File -> Settings。
步骤1 - 进入 Plugins -> Marketplace，搜索“git commit message helper”，点击 Install。
步骤2 - 安装后，在 Installed 选项卡中确认安装成功。
步骤3
插件使用
- 提交代码时，点击Git工具栏中的插件图标。
使用步骤1 - 在弹出的窗口中填写规范的提交信息。
使用步骤2
2. Git提交描述格式规范解析
规范的Git提交信息包含三个部分：Header（头）、Body（体） 和 Footer（脚），与插件界面对应。
标准格式如下：
text
# Header
():
# Body
# Footer2.1 Header（头）
Header只有一行，包含三个字段：type（必需）、scope（可选）、subject（必需）。
| 字段 | 是否必需 | 描述 |
|---|---|---|
| type | 必需 | 提交类型 |
| scope | 可选 | 提交影响范围 |
| subject | 必需 | 提交简短描述 |
-
type（提交类型）：必须使用下表中的标识。
类型 描述 feat 新增功能 fix 修复Bug docs 文档更新 style 代码格式调整（不影响功能） refactor 代码重构 perf 性能优化 test 测试相关 build 构建系统或外部依赖变更 ci CI配置文件或脚本变更 chore 其他杂项（如构建流程、工具库变更） revert 回滚提交 -
scope（作用范围）：说明提交影响的范围，例如模块名或功能名，如
user-module、auth。 -
subject（主题）：简短的描述，概括本次提交的内容，建议在5-10个字以内，例如“用户登录模块添加验证码”。
2.2 Body（体）
对本次提交进行详细描述，说明修改的背景、原因、逻辑或解决方案。例如：“因分布式锁超时设置不当导致死锁，本次调整了锁的超时时间和重试机制。”
2.3 Footer（脚）
包含两个可选字段：Breaking Changes 和 Closed Issues。
| 字段 | 描述 |
|---|---|
| Breaking Changes | 描述不兼容的变动（不常用） |
| Closed Issues | 关联并关闭的Issue，如 Closes #123 |
- Breaking Changes：如果本次提交与上一版本不兼容，需在此说明变动原因及迁移方法。
- Closed Issues：如果本次提交解决了某个Issue或Bug（如禅道任务），可在此注明，例如
Closes #1026。
2.4 完整填写示例
3. 实例Git提交解析
案例一：短信模块新功能提交
场景：为短信模块新增发送状态回调功能。
案例二：用户模块Bug修复提交
场景：修复禅道Bug #1026（用户头像上传失败问题）。
案例三：迭代SQL脚本提交
场景：为版本迭代提交数据库变更脚本。
总结
本文以IDEA插件 Git Commit Message Helper 为切入点，系统介绍了Git提交描述规范的重要性、标准格式（Header/Body/Footer）及各部分填写要求，并通过多个实际开发场景（新功能、Bug修复、SQL脚本）演示了规范提交的全过程。希望读者能认识到统一提交规范对团队协作和项目维护的益处，并在实践中加以应用。
本文参考自外部技术博客，内容已进行优化整理。
评论