在个人项目的早期阶段，我们往往习惯于随意地提交代码：update、fix bug，甚至是一个单独的 .。然而，当项目周期拉长，或者开始与他人协作、参与开源社区时，这种随意的习惯会迅速带来灾难——在排查历史 Bug 或进行代码回滚时，杂乱无章的 git log 犹如大海捞针。

建立 Git Commit 规范，不仅是为了让提交历史看起来整洁，更是为了降低沟通成本、实现自动化（如自动生成 Changelog），以及方便未来的自己进行“代码考古”。

目前开源社区中最为主流的标准是约定式提交（Conventional Commits）。本文将对其核心规则与日常最佳实践进行梳理。

一、核心规则：约定式提交拆解

约定式提交要求每次提交信息必须符合固定的结构：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

在日常开发中，我们最常用的是第一行（Header）。它由三个部分组成：

1. Type（提交类型）

Type 用于明确指出这次提交的性质。严谨界定 Type 是规范的核心，以下是常用的类型及其边界：

• feat: 新增功能（Feature）。
• fix: 修复 Bug。
• docs: 仅包含文档的修改（如 README、接口注释）。
• style: 代码格式变动（不影响代码逻辑，如空格、缩进、去除多余空行等）。
• refactor: 代码重构（注意边界：既不是新增功能，也不是修复 Bug 的代码变动）。
• perf: 优化性能的代码修改。
• test: 添加缺失的测试或更正现有测试。
• chore: 构建过程、辅助工具或依赖库的变动（如更新 npm 包、修改 webpack 配置）。

2. Scope（作用域）

Scope 用于说明 commit 影响的范围，比如 auth、router、db 等。它可以帮助团队成员快速定位改动发生的模块。例如： feat(auth): 新增 JWT 登录支持。

3. Description（描述）

简短地描述改动内容。几个书写建议：

• 动宾结构：以动词开头，如“新增 xxx”、“修复 xxx”。
• 精简准确：不要超过 50 个字符，说清楚“做了什么”即可。

二、最佳实践：Commit 的颗粒度与习惯

仅仅记住格式是不够的，规范的落地还需要良好的工程习惯支撑。

1. 控制合理的提交颗粒度

一个 Commit 应该只包含一个逻辑上的改动。 这是新手最容易踩的坑。如果在开发新功能时顺手修复了一个历史 Bug，或者格式化了整个文件，请务必将它们拆分为多个独立的 Commit（例如一个 feat，一个 fix，一个 style）。

过大的、揉捏了各种变动的 Commit 会让代码审查（Code Review）变得异常困难，一旦新功能引发线上故障，想要单纯回滚那个附带的 Bug 修复几乎不可能。

2. 关联 Issue 或任务流

如果是为了解决某个特定的 Issue 或需求，应该在提交信息中（通常在 Footer 部分，或者直接在 Description 末尾）附带 Issue 编号。例如： fix(user): 修复并发注册时的锁问题 (#123)

主流的托管平台（如 GitHub、GitLab）会自动将这个 Commit 与对应的 Issue 关联并闭环。