Git Commit 提交规范

最新推荐文章于 2025-10-11 13:44:32 发布

原创最新推荐文章于 2025-10-11 13:44:32 发布 · 2.5k 阅读

34 ·

CC 4.0 BY-SA版权

文章标签：

#git

Git Commit 规范是一套约定俗成的规则，用于统一代码提交信息的格式和内容。它可以帮助团队更清晰地记录代码变更历史，方便回溯问题、生成更新日志（CHangelog）或自动化版本管理。以下是常见的规范和实践：

1. 基本格式

一个规范的 Commit Message 通常包含 Header、Body 和 Footer 三部分：

<类型>(<作用域>): <主题>
<空行>
[正文]
<空行>
[脚注]

示例

feat(user): 新增用户登录功能

- 支持邮箱和手机号登录
- 添加第三方登录入口

Closes #123

2. 核心字段说明

类型（Type）

指明本次提交的目的，常用类型如下：

类型	说明
`feat`	新增功能
`fix`	修复问题/BUG
`docs`	文档更新（如 README、注释）
`style`	代码格式调整（如空格、分号，不影响逻辑）
`refactor`	代码重构（既不修复 BUG 也不新增功能）
`test`	测试相关（新增测试用例或修改测试代码）
`chore`	构建/工具/依赖的改动（如 Webpack 配置、npm 脚本）
`perf`	性能优化
`ci`	持续集成相关的修改（如 GitHub Actions、Jenkins）
`revert`	回滚之前的提交

作用域（Scope）

可选字段，表示修改的影响范围（如模块、组件、文件名）：

例如：feat(user), fix(api), docs(README)

主题（Subject）

简明扼要的说明，建议：

使用动词开头（如 “新增”、“修复”、“优化”）
首字母小写，结尾不加句号
英文推荐使用祈使句（如 Add user login feature）

正文（Body）

可选，详细描述修改内容，例如：

改动的背景和原因
与之前行为的对比
技术实现的关键点

脚注（Footer）

可选，用于关联 Issue 或标注破坏性变更：

关闭 Issue：Closes #123, #456
重大变更（BREAKING CHANGE）：
```
BREAKING CHANGE: 移除旧版 API
```

3. 规范的价值

清晰的提交历史：快速定位特定类型的修改（如 feat/fix）。
自动化生成 CHANGELOG：根据类型自动归类更新内容。
触发语义化版本号：结合工具（如 standard-version）自动升级版本号：
- feat → 小版本（Minor）
- fix → 修订版本（Patch）
- BREAKING CHANGE → 主版本（Major）
提高代码审查效率：通过提交信息快速理解改动意图。

4. 工具支持

1. Commitizen

交互式生成规范提交信息：

npm install -g commitizen
commitizen init cz-conventional-changelog --save-dev --save-exact

使用：git cz 替代 git commit

2. Commitlint

校验提交信息是否符合规范：

# 安装
npm install --save-dev @commitlint/cli @commitlint/config-conventional
# 配置文件 .commitlintrc.js
module.exports = { extends: ['@commitlint/config-conventional'] };

3. Husky

添加 Git 钩子，在提交前自动检查：

npx husky install
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"'

5. 扩展规范

Conventional Commits：社区广泛采用的规范，详见 conventionalcommits.org
Angular 规范：最早提出并实践的 Commit 规范，细节略有不同。

通过遵循一致的提交规范，团队可以显著提升协作效率和代码可维护性。建议在项目初期约定规则，并通过工具强制执行。