Git提交规范feat、fix、chore详解

在团队协作开发中，Git 提交信息如果写得太随意，例如“修改”“再改改”“fix bug”，很快就会让提交历史变得难以阅读。feat、fix、chore` 是 Conventional Commits 规范中最常用的三类提交类型，它们分别表示新增功能、修复缺陷和日常维护。 统一使用这些前缀，不仅能提高代码审查效率，还能支持自动生成 CHANGELOG 和语义化版本管理。

一、提交信息的基本格式

规范的提交信息通常由类型、可选作用域和描述组成：

<type>(<scope>): <description>

其中 type 表示提交类型，必须使用固定值；scope 表示影响范围，例如 auth、ui、api，可选但推荐填写；description 是简短描述，应说明“做了什么”。 示例如下：

feat(auth): 添加手机号验证码登录
fix(order): 修复订单状态更新失败问题
chore: 更新依赖版本

如果修改涉及破坏性变更，可以在类型后加 !，或在脚注中写 BREAKING CHANGE。

二、feat：新增功能

feat 是 feature 的缩写，用于表示向项目新增了用户或调用方可感知的新功能。 如果只是调整内部实现，但没有新增能力，不应使用 feat。

常见示例包括：

feat: 支持暗黑模式
feat(payment): 新增支付宝支付方式
feat(api): 增加用户批量导入接口

在语义化版本控制中，feat 提交通常对应小版本号升级，例如从 1.2.0 升级到 1.3.0。

三、fix：修复缺陷

fix 用于修复 bug 或纠正不符合预期的行为。 它强调“修复问题”，而不是新增功能或单纯重构。提交 fix 时，最好说明修复了什么缺陷，必要时可关联 issue 编号。

常见示例包括：

fix: 修复空购物车结算报错
fix(login): 修复验证码过期后仍可提交的问题
fix(ui): 修复 Safari 下按钮错位问题

fix 提交通常对应补丁版本升级，例如从 1.2.0 升级到 1.2.1。

四、chore：日常维护

chore 表示不直接影响业务逻辑或运行功能的维护性工作。 它通常用于构建脚本、依赖管理、配置文件、脚手架调整等场景。需要注意的是，chore 不应与 feat、fix 混用；如果一次提交既修复 bug 又更新依赖，应拆分为多次提交。

常见示例包括：

chore: 更新 package.json 依赖
chore: 配置 ESLint 规则
chore(ci): 调整 GitHub Actions 构建流程

如果修改的是文档，通常更适合使用 docs；如果修改的是代码格式，更适合使用 style；如果涉及 CI/CD 流水线，则可使用 ci。

五、使用注意事项

第一，保持类型准确。新增能力用 feat，修复问题用 fix，维护杂项用 chore，不要把所有修改都写成 chore。第二，描述应简洁明确，避免“修改代码”“优化一下”这类模糊表达。第三，作用域可选，但如果项目模块较多，填写作用域能显著提升可读性。 第四，提交粒度要适中，一次提交尽量只做一件事，避免功能开发、bug 修复和依赖升级混在一起。第五，团队应统一规范，并可通过 Commitizen、husky、commitlint 等工具进行校验。

feat、fix、chore 是 Git 提交规范中最基础也最常用的三类类型。feat 表示新增功能，fix 表示修复缺陷，chore 表示日常维护。它们配合规范格式 <type>(<scope>): <description> 使用，可以让提交历史更清晰、更便于追溯和自动化处理。实际项目中，团队应在 Conventional Commits 基础上约定适合自身的类型集合，并坚持小粒度、准确描述、统一校验，从而提升协作效率和版本管理质量。

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com