当前位置：首页 > article >正文

【github 使用相关】提交pr和commit message Conventional Commits 规范代码提交的描述该写什么？

article 2025/3/1 21:18:40

Git 提交信息格式

格式描述

一般开源项目代码库根目录都会有一个 CONTRIBUTING.md 或者其他类似名字的文档来介绍如何开始贡献，像https://github.com/imputnet/cobalt/blob/main/CONTRIBUTING.md。贡献代码时需要注意 commit message 的规范，可能每个开源项目的要求不尽相同，但大多遵守以下的conventional commits(中文版)格式：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

提交信息通常分为三部分，主要由 subject 和 body 组成：
1. Subject（标题）：简短、简洁的一行描述，通常限制在 50 字符以内。
2. 空行：在 subject 和 body 之间留一个空行，以区分两部分。
3. Body（正文）：提供更详细的描述，包括为什么做这个修改、修改的内容、相关的上下文等。建议每行长度限制为 72 个字符。

Subject（标题）

简短描述：不超过 50 个字符，描述改动的主题。
使用标签：用类型标签开头，描述改动的操作类型。
没有句号：标题行不加句号。

Body（正文）

解释背景和动机：详细描述为什么做这个改动？有无相关的 bug 或任务？
描述具体修改内容：改动了什么，解决了什么问题。
每行限制在 72 个字符以内：使得正文内容更加易于阅读，特别是在终端或者 Git 日志中查看时。

规范的标签（Tag）

在提交 Git commit message 时，使用规范的标签（Tag）有助于清晰地表达提交内容，方便团队协作和版本管理。

feat：新增功能（feature）
示例：feat: 新增用户登录功能
fix：修复 Bug
示例：fix: 修复登录页面崩溃问题
docs：仅文档修改（Documentation）
示例：docs: 更新接口文档
style：代码格式调整，不影响功能（不涉及逻辑修改）
示例：style: 格式化代码，调整缩进
refactor：重构代码（不影响功能和修复 Bug）
示例：refactor: 优化登录逻辑，提升代码可读性
chore：其他杂项（构建、依赖管理、脚本任务）
示例：chore: 更新依赖包版本
perf：性能优化（Performance）
示例：perf: 优化数据加载速度
test：新增或修改测试代码
示例：test: 增加登录接口单元测试
ci：CI/CD 配置修改（持续集成相关）
示例：ci: 修改GitHub Actions配置
build：构建相关的修改（如webpack、rollup配置）
示例：build: 调整打包配置，支持多环境打包
revert：回滚之前的提交
示例：revert: 回滚错误的提交 abc123
wip（Work In Progress）：进行中的工作，未完成的任务
示例：wip: 页面样式调整中
feat+fix：新增功能并修复相关 Bug
示例：feat/fix: 增加注册功能并修复输入校验问题
chore+docs：更新依赖并调整文档
示例：chore/docs: 更新依赖并修复API文档错误

示例

feat: Add **** to utilize **** // 添加新性能的commit message

新增了登录功能，并且是为了利用用户身份验证 API

feat: Add login functionality to utilize user authentication API

修改了某个 bug，并且用方法 A 替换了方法 B：

fix: Replace method B with method A to resolve issue with data processing

完整示例：

fix: Replace method A with method B in test to handle IndexedDB async read issue across browsers

Due to occasional issues with IndexedDB async reads across different browser versions, method B is used in the test to ensure consistent behavior and data processing.