【规范】Git Commit 约定式提交规范
文章目录
- 前言介绍
- 使用约定式提交规范的好处
- 提交信息格式
- 信息头部(Header)
- 正文(Body)
- 脚注(Footer)
- 撤销(Revert)
- 提交类型表格
- 官网
前言介绍
约定式提交规范它是一种基于提交信息的轻量级约定,提供了一组简单规则来创建清晰的提交历史。
使用约定式提交规范的好处
使用约定式提交规范的好处有哪些呢?
- 提高开发效率:通过这种 “约定大于配置” 的思想,约定式提交减少了软件开发人员需要做的决定数量,从而提升了开发效率。
- 便于历史记录和版本控制:约定式提交要求每次使用 git commit 时都需要写 commit message,并且如果 message 的 style 是按照固定的模板格式书写,这对于后期的维护和编写 changelog(更新版本) 都有巨大的好处。按照这个格式看起来一目了然。
- 提升代码可读性:约定式提交通过使用固定的模板格式书写提交信息,使得commit message具有更好的可读性,清晰明了。这不仅便于团队成员之间的沟通和协作,也为 Code Reviewing 做好了准备,无需深入查看代码即可了解当前 commit 的作用。
- 减少错误和混乱:通过规范化提交(无论是文中提到的具体方式还是其他统一、简明的方式),可以避免在 commit 时五花八门的提交信息,减少在处理问题时耗费的时间。这有助于提高代码库的质量和可维护性,避免因提交信息不规范而导致的混乱和错误。
提交信息格式
<类型>[可选 范围]: <描述>
[可选 正文]
[可选 脚注]
信息头部(Header)
Header 部分只有一行,包括三个字段:type(必需)、scope(可选)和 subject(必需)。
Type 使用的类型哪一个请看下面的提交类型表格。
Scope 用于说明提交影响的范围,比如数据层、控制层、视图层等,每个项目的架构不同,所以视角是不一样的。
Subject 是提交目的的简短描述,不超过50个字符。
正文(Body)
Body 部分是对本次 Commit 的详细描述,可以分成多行。
脚注(Footer)
Footer 部分一般用于两种情况。
1、不兼容变动:如果当前代码与上一个版本不兼容,则 Footer 部分以 BREAKING CHANGE 开头,后面是对变动的描述、以及变动理由和迁移方法。
2、关闭 Issue、项目内部测试案例,或者关闭项目内部BUG号:比如说当前 Commit 针对某个 issue,那么可以在 Footer 部分写上关闭这个 issue 。
如:Close #234, #123
撤销(Revert)
Revert 是一种特殊情况,用于撤销以前的 Commit。其必须以 revert: 开头,后面跟着被撤销 Commit 的 Header。
而 Revert 中的 Body 部分是有一种固定格式的,则需要写成 This reverts commit commit_id
revert: feat ✨: 添加用户功能
This reverts commit bc3f0184.
注意:以上不管是哪一个部分,任何一行都不得超过 72 个字符(或100个字符),这是为了避免自动换行影响美观。
提交类型表格
提交类型 | 标题 | 描述 | Emoji |
---|---|---|---|
feat | Features | 新增功能 | ✨ |
fix | Bug Fixes | 修复 BUG | 🐛 |
docs | Documentation | 修改文档 | 📚 |
style | Styles | 不影响代码含义的更改(空格、格式、缺少分号等) | 💎 |
refactor | Code Refactoring | 代码重构,无新功能或修复Bug | 📦 |
perf | Performance Improvements | 优化相关,比如提升性能,体验 | 🚀 |
test | Tests | 增加测试用例,包括单元测试,集成测试等 | 🚨 |
build | Builds | 影响构建系统或外部依赖项的更改(示例范围:gulp、broccoli、npm) | 🛠 |
ci | Continuous Integrations | 对我们的 CI 配置文件和脚本的更改(示例范围:Travis、Circle、BrowserStack、SauceLabs) | ⚙️ |
chore | Chores | 改变构建流程,增加依赖库,工具等 | ♻️ |
revert | Reverts | 回滚到上一个版本 | 🗑 |
官网
官网地址,可以去查看原文