
🏀事情起因:
在工作迭代过程中,偶然发现同组小帅哥Git提交描述总是和自己的不大一样,秉承好奇至上的我特意去研究了下。竟然发现提交了这么多年的Git描述竟然不符合规范,遂总结一下大厂和一些开源项目的的Git提交规范,跟大家分享一下。




🔔 分析
在团队开发中,一般都会使用Git 版本控制工具来管理代码,每个组员提交代码时都会写 commit message。如果没有一个统一标准规范,每个人都有自己的风格,项目小成员少还好,如果团队成员多,项目复杂,十分不利于阅读管理和维护。
通过上方图中提交记录对比,明显感觉上方Git提交记录较为规范美观。虽然本狗写的提交记录也比较清晰,但是随着项目推进及人员的混杂,规范标准必须执行!
因此为了后期一劳永逸,需要制定统一标准,提交记录清晰明了,让团队一看就能知道此次提交的目的,减少管理时间成本。
一个可帮助您标准化提交内容的插件







Header头只有一行,包括3个字段: type(必需), scope(可选), subject(必需)
属性 | 描述 |
|---|---|
type(必填) | commit提交类型 |
scope(选填) | commint提交影响范围 |
subject(必填) | commint提交简短描述 |
type说明提交类型:只允许使用下面属性
属性 | 描述 |
|---|---|
feat | 新功能 |
fix | 修改bug |
docs | 文档修改 |
style | 格式修改 |
refactor | 重构 |
perf | 性能提升 |
test | 测试 |
build | 构建系统 |
ci | 对CI配置文件修改 |
chore | 修改构建流程、或者增加依赖库、工具 |
revert | 回滚版本 |
scope说明提交影响范围:一般是修改的什么模块或者是什么功能,如【xx模块】/【xx功能】
subject 说明提交简短描述:一般是5-10各自简单描述做的任务,如【xx模块加入消息队列】
body说明提交详细描述:对于功能详细的描述,解释为什么加入这段代码,为什么调整优化等,如因分布式锁问题,导致死锁问题,优化调整xxxx
.Footer脚包括2个字段: Breaking Changes、Closed Issues
属性 | 描述 |
|---|---|
Breaking Changes | 中断性不兼容变动(不常用) |
Closed Issues | 关闭Issues问题 |
当前版本与之前版本不兼容,如迭代升级对之前版本不能做到兼容,就需要在Breaking Changes后面描述变动理由和迁移方法之类,此属性不常用







本文通过IDEA中Git描述规范插件【git commit message helper】为契机,介绍Git提交描述的规范流程步骤,最后以实际例子作为体验对象,融汇插件及规范流程,实操Git Commit提交描述。希望大家能体会到流程的好处,团队规范统一的益处。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。