在软件开发过程中，代码提交信息是项目历史的重要组成部分，清晰、规范的提交信息能极大提升团队协作效率和项目可维护性。Conventional Commits 规范作为一套被广泛认可的提交信息标准，为开发者提供了明确的指引。本文将从该规范的基础内容讲起，详细解析常见的提交类型，帮助大家全面掌握这一实用规范。
一、Conventional Commits 规范基础
Conventional Commits 是一种基于约定的提交信息规范，它为提交信息设定了统一的格式和内容要求，目的是让提交历史具有一致性和可预测性。通过遵循这一规范，每个代码提交都能传递出清晰的变更意图，让其他开发者能快速理解提交的目的和内容。
（一）规范的结构
Conventional Commits 规范的提交信息结构通常如下：
<类型>[可选 作用域]: <描述>[可选 正文]
[可选 脚注]
类型：提交信息的核心部分，用于说明提交的性质，如新增功能、修复 bug 等。
作用域：可选部分，用于指定提交影响的范围，如某个模块、组件等，能帮助精准定位变更所在。
描述：对提交内容的简短总结，需简洁明了，通常不超过 50 个字符，且以动词开头，使用现在时。
正文：可选部分，用于详细描述提交的内容、原因、解决的问题等，可分多行。
脚注：可选部分，主要包含额外信息，如不兼容变更（以 “BREAKING CHANGE:” 开头）、关联的 issue 编号（如 “Closes #123”）等。
（二）遵循规范的优势
提高代码可读性：规范的提交信息让开发者能快速了解每次代码变更的目的和内容，减少理解成本，回顾历史提交时无需逐个查看代码细节。
便于协作开发：在团队开发中，规范的提交信息能让成员间更好地协作，避免重复工作，如一个开发者修复 bug 后，其他成员通过提交信息就能知晓情况。
自动化生成版本日志：借助 standard-version、semantic-release 等工具，可自动分析符合规范的提交信息，生成清晰准确的版本日志，提高工作效率。
辅助语义化版本控制：提交类型与语义化版本（MAJOR.MINOR.PATCH）相对应，“feat” 可能对应 MINOR 版本更新，“fix” 可能对应 PATCH 版本更新，含 “BREAKING CHANGE” 可能对应 MAJOR 版本更新，有助于规范版本控制。
（三）拓展与工具支持
拓展类型：除常见类型外，团队可根据自身需求添加自定义类型，如 “wip”（工作进行中）、“revert”（回滚提交）等，以适应项目特点。
工具支持：commitlint 可检查提交信息是否符合规范，husky 能在提交前触发 commitlint 检查；cz-cli 等交互式提交工具可引导开发者按规范填写信息，降低使用难度。
二、常见提交类型详解
在 Conventional Commits 规范中，提交类型是体现代码变更性质的核心要素，准确理解和使用各种类型，能让提交信息更精准地传递变更意图。
（一）feat：新功能
含义：用于标识在代码中新增了面向用户的功能，这些功能能为产品带来新的能力或特性。
应用场景：电商平台添加购物车功能，社交软件新增朋友圈发布功能等。
示例：feat(shop): 新增商品加入购物车功能，明确在 “shop”（商店）模块新增了加入购物车功能。
（二）fix：修复 bug
含义：表示修复了代码中导致程序运行异常、功能无法正常使用等问题的错误。
应用场景：修复用户登录时输入正确密码却提示错误的问题，解决订单提交后数据未正确保存的 bug 等。
示例：fix(login): 修复输入正确密码却登录失败的问题，指出在 “login”（登录）模块修复了特定 bug。
（三）docs：文档变更
含义：仅涉及文档内容的修改，不影响代码的实际运行逻辑。
应用场景：更新项目的 README 文件，完善 API 文档的说明，修改注释文档等。
示例：docs(api): 更新接口文档的参数说明，说明对 “api”（接口）相关文档进行了参数说明更新。
（四）style：代码风格调整
含义：对代码的格式、排版等进行调整，不改变代码的功能和逻辑。
应用场景：调整代码的缩进方式，修改变量命名的大小写，添加或删除空格、空行等。
示例：style: 统一代码缩进为4个空格，表明此次变更只是统一了代码的缩进风格。
（五）refactor：代码重构
含义：既不是新增功能，也不是修复 bug，而是优化现有代码的结构、逻辑等，以提高代码的可读性、可维护性或性能，但不改变代码的外部行为。
应用场景：将过长的函数拆分成多个小函数，更换数据结构以提高查询效率，简化复杂的条件判断等。
示例：refactor(cart): 拆分购物车计算总价的复杂函数，说明在 “cart”（购物车）模块对计算总价的函数进行了重构。
（六）perf：性能优化
含义：专门针对代码的性能进行改进，旨在提高程序的运行速度、降低资源消耗等。
应用场景：优化数据库查询语句，减少不必要的循环操作，提升页面加载速度等。
示例：perf(list): 优化商品列表加载速度，表示对 “list”（列表）模块的商品列表加载性能进行了优化。
（七）test：添加或修改测试用例
含义：涉及测试相关的代码变更，包括新增测试用例、修改现有测试用例等，以保证代码的质量和稳定性。
应用场景：为新添加的功能编写单元测试，修正因代码变更导致失败的测试用例等。
示例：test(user): 为用户注册功能添加单元测试，说明在 “user”（用户）模块为注册功能新增了单元测试。
（八）chore：构建过程或辅助工具的变动
含义：主要是对项目的构建流程、依赖管理、辅助工具等进行修改，不直接影响业务代码。
应用场景：更新项目的依赖包版本，修改构建脚本，配置 CI/CD 流程等。
示例：chore: 更新项目依赖包至最新版本，表明此次变更是对项目依赖包进行了更新。
三、实践建议
团队共识：推广规范时，让团队成员达成共识，通过培训、文档等方式普及规范的重要性和使用方法。
逐步过渡：若团队之前未使用过类似规范，可先从重要项目或模块开始尝试，再逐步推广到整个团队和所有项目。
结合工具：利用相关工具辅助规范执行，减少人工检查成本，提高执行效率和准确性。
定期回顾与调整：实践中定期回顾规范使用情况，根据项目实际需求和团队反馈，对规范进行适当调整优化，使其更符合团队开发习惯。
总之，Conventional Commits 规范为代码提交信息提供了简单有效的标准，掌握其基础内容和常见类型，遵循规范进行代码提交，能让代码提交历史更清晰可读，提升团队协作效率，为项目开发和维护带来诸多益处。