git怎么使用Conventional Commits

掌握Git提交的艺术：详解Conventional Commits规范与实践

在日常开发中，我们经常面对杂乱无章的Git提交历史，修复了一个bug”、“更新了代码”等模糊不清的描述，这不仅让回溯问题变得困难，也使得团队协作效率低下。Conventional Commits 正是为了解决这一问题而诞生的一套轻量级、约定式的提交消息规范。

它的核心价值在于：

一个符合规范的提交消息由以下几个可选的组成部分构成,遵循以下格式：

<类型>[可选的作用域]: <描述>
[可选的脚注]

类型（Type）：用于表明本次提交的性质，是规范的核心,常见的类型包括：
- feat：新增功能。
- fix：修复Bug。
- docs：仅文档更改。
- style：不影响代码含义的更改（如空格、格式化等）。
- refactor：既不修复错误也不添加功能的代码重构。
- perf：性能优化。
- test：添加或修改测试。
- chore：对构建过程或辅助工具和库（如文档生成）的更改。
作用域（Scope）：可选部分，用于说明提交影响的范围，例如某个模块、组件或文件（如 auth， user-api， navbar）。
描述（Description）：对本次提交的简洁概括，使用祈使句、现在时态，add”而非“added”或“adds”。
正文（Body）：可选部分，用于提供更详细的解释,说明更改的动机以及与之前行为的对比。
脚注（Footer）：可选部分,通常用于两种情况：
- 关联问题单（Issue）：如 Closes #123， Fixes ww.jxysys.com/issue/456。
- 标记重大变更（BREAKING CHANGE）：以BREAKING CHANGE:开头，后跟描述,说明不兼容的变动。

示例：

feat(auth): 添加用户通过邮箱登录功能
- 新增邮箱验证码发送接口
- 完善登录逻辑，兼容邮箱与用户名登录
- 更新相关API文档
Closes #42

将规范融入日常Git操作非常简单,以下是一个典型的工作流程：

创建或切换功能分支：
```
git checkout -b feat/user-avatar-upload
```
完成开发并进行暂存：
```
git add .
```
提交更改（关键步骤）：
- 命令行直接提交：在git commit时仔细撰写符合规范的消息。
```
git commit -m "feat(user): 支持用户头像上传至云存储"
# 或使用 -m 多行输入正文和脚注
git commit -m "fix(api): 修复分页查询总数返回错误" -m "调整SQL count语句，避免NULL值影响" -m "Fixes #58"
```
- 使用交互式提交（推荐）：使用 git commit 不加 -m 参数，会打开默认编辑器（如Vim、VSCode），可以更从容地编写结构清晰的提交信息，包括标题、正文和脚注。
推送分支并创建合并请求（Pull Request）：
```
git push origin feat/user-avatar-upload
```
在代码托管平台（如GitHub， GitLab）上，基于清晰规范的提交记录,可以非常方便地创建和审查合并请求。

手动记忆和书写规范可能会出错,以下工具能极大提升效率和准确性：

Commitizen：一个强大的交互式命令行工具，通过 git cz 命令代替 git commit，它会一步步引导你选择类型、作用域、填写描述等,生成完美格式的提交信息。
Commitlint：一个提交消息校验工具，可以将其集成到项目中，在提交时或作为CI/CD的一环，自动检查提交消息格式是否符合规范,不符合则阻止提交。
IDE插件：许多主流编辑器（如VSCode）都有支持Conventional Commits的插件，提供类型选择、自动补全和语法高亮。
语义化版本与变更日志生成：结合 standard-version 或 semantic-release 等工具，可以根据 feat 和 fix 等提交类型，自动决定版本号升级,并生成精美的变更日志。

Q1：如果一次提交包含了多种类型的更改怎么办？ A：理想情况下，一次提交应只做一件事，如果包含了多种类型（如同时修复bug和重构），应优先考虑将提交拆分成多个更小、更专注的提交，如果实在无法拆分，根据主要目的选择最重要的类型,并在正文中详细说明。

Q2：类型可以自定义吗？ A：可以，但不建议，规范定义的核心类型已覆盖绝大部分场景，自定义类型会导致工具链（如自动生成CHANGELOG）失效或需要额外配置，如果团队有特殊需求,应在团队内达成一致并配置相应的工具。

Q3：如何让团队所有成员都遵守这个规范？ A：在团队内进行宣导和培训，解释其价值，在项目中引入 Commitlint 进行强制校验，并将检查步骤加入CI流程，可以通过代码审查（Code Review）来温和地提醒和纠正不规范的提交。

Q4：规范的提交信息对开源项目有什么特别的好处？ A：对于开源项目，规范的提交信息是无价的，它能让贡献者快速理解项目演进脉络，降低参与门槛，维护者也能更高效地管理Issue和PR，自动化发布流程,显著减轻维护负担。

Conventional Commits不仅仅是一个格式规范，它更是一种倡导清晰、高效协作的开发哲学，通过将松散的提交信息结构化，它连接了代码变更、版本管理和自动化流程,为项目的可维护性和团队的专业性带来了质的提升。

从下一个提交开始，尝试使用 feat: 或 fix: 作为开头，逐步在团队中推广，并借助 Commitizen 等工具降低上手门槛，当整洁有序的提交历史和自动生成的变更日志呈现在你眼前时，你将会深刻体会到这份“约定”所带来的巨大收益。

立即访问 ww.jxysys.com 获取更多关于Git高级实践与团队效能提升的深度教程和工具推荐,助力你和你的团队打造更卓越的工程实践。