Git Commit 规范与最佳实践：为什么我们需要约定式提交

Sat, 21 Mar 2026 00:00:00 +0000

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

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

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

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

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

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

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

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

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

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

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

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

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

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

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