Git 提交规范：写出优雅而高效的 Commit Message
在软件开发中，git commit 是我们每天都要执行无数次的操作。然而，我们常常忽略了提交信息（Commit Message）的质量。一个清晰、规范的 Commit Message 不仅能让协作者快速理解代码变更的目的，还能极大地提升项目维护的效率，甚至可以自动化生成发布日志 (Changelog)。
本文将介绍业界广泛遵循的提交规范，并提供实用工具，帮助你和团队养成良好习惯。
为什么我们需要规范的 Commit Message？
很多人可能会问：“代码本身就是文档，为什么还要在注释上花这么多心思？” 事实是，规范的 Commit Message 能带来诸多好处：
- 提供清晰的历史记录：当你想回顾某个功能的演进，或者定位一个 Bug 是何时引入的 (
git bisect)，清晰的日志让你一目了然。 - 加快 Code Review 过程：审查者可以通过 Commit Message 快速了解每个变更的目的，而无需深入每一行代码的细节。
- 自动化生成文档：遵循特定规范（如 Conventional Commits）可以直接从 Git 历史中生成项目的更新日志 (Changelog)。
- 方便团队协作：统一的规范降低了团队成员之间的沟通成本，新成员也能更快地融入项目。
主流规范：Conventional Commits
目前，社区中最流行、最完善的方案是 Conventional Commits (约定式提交) 规范。它受到了 Angular 提交指南 的启发，格式简洁，扩展性强，并且对工具有良好的支持。
格式总览
约定式提交的格式如下：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
它主要由三个部分组成：Header (头部)，Body (正文) 和 Footer (页脚)。其中，Header 是必需的，而 Body 和 Footer 是可选的。
1. Header (头部)
Header 只有一行，包含三个字段：type (类型)，scope (范围，可选) 和 subject (主题)。
type (必需): 用于说明本次提交的类别。常用的 type 如下：
feat: 新增功能 (feature)。fix: 修复 Bug。docs: 仅仅修改了文档，比如 README, CHANGELOG 等。style: 修改代码格式，不影响代码逻辑 (比如修改空格、分号等)。refactor: 代码重构，没有新增功能或修复 Bug。perf: 性能优化。test: 新增或修改测试用例。build: 修改项目构建系统或外部依赖（例如 antd, vite, webpack)。ci: 修改持续集成（CI）相关的配置文件和脚本。chore: 其他不修改源码或测试的杂项修改，例如更新 .gitignore 文件。revert: 回滚到之前的某次提交。
scope (可选): 用于描述本次提交影响的范围，比如某个模块、组件或功能。例如 feat(user-api):、fix(login-form):。
subject (必需): 本次提交的简短描述。
- 以动词开头，使用第一人称现在时，例如
add，而不是added或adds。 - 第一个字母小写。
- 结尾不加句号 (
.)。
Header 示例:
feat(user): add user registration endpoint
fix(header): correct navigation link alignment
docs: update installation guide
2. Body (正文)
Body 部分是对 subject 的补充，可以分成多行，用以详细描述代码变更的背景和动机。
- 解释“为什么”要这么做，而不是“如何”做。
- 应详细说明变更前后的行为差异。
Body 示例:
fix(api): prevent rate limit errors
The previous implementation did not handle API rate limits,
causing the application to crash when making too many requests
in a short period.
This commit introduces a rate-limiting mechanism with exponential
backoff to gracefully handle such scenarios.
3. Footer (页脚)
Footer 部分通常用于两种情况：
- 标记重大变更 (Breaking Change)：如果当前的变更是破坏性的（即不向下兼容），必须在 Footer 中以
BREAKING CHANGE:开头，后面跟上对变更的描述、理由和迁移方法。 - 关联 Issue：如果本次提交关闭了某个 Issue，可以在这里引用。例如
Closes #123或Fixes #456。
Footer 示例:
BREAKING CHANGE: The `getUser` API endpoint now requires an `Authorization` header.
Users must update their clients to include a valid JWT token in all requests.
Closes #234
完整示例
一个包含了所有部分的完整 Commit Message 如下：
feat(auth): implement JWT-based authentication
Implement a new authentication flow using JSON Web Tokens (JWT) instead of session cookies. This enhances security and prepares for stateless API architecture.
The old session-based authentication is now deprecated and will be removed in v2.0.0.
BREAKING CHANGE: The login endpoint `/api/login` now returns a JWT token instead of setting a session cookie. Clients need to be updated to store this token and send it in the `Authorization` header.
Fixes #101, Closes #102
实践工具
手动维护规范很困难，幸运的是，社区提供了强大的工具来帮助我们自动化这一过程。
- Commitizen: 一个命令行工具，通过交互式问答的方式，引导你生成符合规范的 Commit Message。
- Husky: 一个 Git Hooks 工具，可以让你在
commit、push等 Git 操作发生前执行自定义脚本。 - commitlint: 一个检查器，用于校验你的 Commit Message 是否符合规范。
通常，我们会将 Husky 和 commitlint 结合使用，在 git commit 时自动检查 message 内容。如果不符合规范，提交将被阻止，从而在源头上保证了提交信息的质量。
总结
规范的 Git 提交注释是专业软件开发中一项投入产出比极高的实践。它不仅提升了个人工作效率，更重要的是，它为团队协作和项目长期维护奠定了坚实的基础。从今天起，就开始在你的项目中实践这些规范吧！