【规范】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 | 回滚到上一个版本 | 🗑 |
官网
官网地址，可以去查看原文