Git 代码提交规范：让团队协作更高效

在日常的代码开发中，我们经常会看到一些提交记录中包含像 feat、fix、chore 这样的词汇。这些看似简单的标签，其实背后是一套规范化的代码提交方式。今天，我们就来聊聊 Git 提交规范的那些事儿。

为什么需要提交规范？

想象一下，当你打开一个项目的提交历史，看到的是一堆模糊不清的描述，比如“修复了一个问题”或者“添加了一些功能”。这样的记录不仅难以理解，还让后续的维护和协作变得困难。而一套清晰的提交规范，能够让我们快速了解每次提交的目的和影响范围，提高团队协作的效率。

规范化的提交信息还能帮助自动化工具更好地解析和处理提交记录，比如生成变更日志（CHANGELOG）或者自动化发布流程。这不仅节省了时间，也让项目更加模块化和易于维护。

常见的提交类型

在 Git 提交规范中，subject 是提交信息的第一部分，用来描述提交的类型。以下是一些常见的 subject 类型及其含义：

1. feat：新功能（feature）

用于提交新功能的代码。

• 示例：feat: 添加用户注册功能

2. fix：修复 bug

用于提交修复问题的代码。

• 示例：fix: 修复登录页面崩溃的问题

3. docs：文档变更

用于提交仅涉及文档的修改。

• 示例：docs: 更新 README 文件

4. style：代码风格变动

用于提交不影响代码逻辑的格式化修改，比如空格、标点符号等。

• 示例：style: 删除多余的空行

5. refactor：代码重构

用于提交既不是新增功能也不是修复 bug 的代码更改。

• 示例：refactor: 重构用户验证逻辑

6. perf：性能优化

用于提交提升性能的代码修改。

• 示例：perf: 优化图片加载速度

7. test：添加或修改测试

用于提交测试相关的代码。

• 示例：test: 增加用户模块的单元测试

8. chore：杂项

用于提交构建过程或辅助工具的变动。

• 示例：chore: 更新依赖库

9. build：构建系统变更

用于提交影响构建系统的更改。

• 示例：build: 升级 Webpack 到版本 5

10. ci：持续集成配置变更

用于提交 CI 配置文件和脚本的修改。

• 示例：ci: 修改 GitHub Actions 配置文件

11. revert：回滚

用于提交回滚之前的提交。

• 示例：revert: 回滚 feat: 添加用户注册功能

提交信息的格式

一个标准的 Git 提交信息通常由以下几部分组成：

复制

<类型>(<范围>): <简短描述>

[空行]

[详细描述]

[空行]

[页脚]

• 类型：如 feat、fix 等。

• 范围：可选，描述提交影响的模块或文件。

• 简短描述：简洁明了地描述提交的核心内容，通常不超过 50 个字符。

• 详细描述：补充说明提交的动机和实现方式。

• 页脚：记录相关链接或 Issue 编号。

示例

feat(user-profile): 添加用户头像上传功能

在用户个人资料页面新增头像上传功能，支持 JPG 和 PNG 格式。

Closes #123

---

希望你喜欢这篇博客文章！请点个赞和收藏吧。祝点赞和收藏的帅哥美女们今年都能暴富。如果有更多问题，欢迎随时提问