Git提交中的perf和chore是什么？

在 Git 的语境里，perf 不是 Git 自带的命令，而更多是指 一种约定俗成的提交类型（commit type） ，常见于使用 约定式提交（Conventional Commits） 或类似的提交规范的团队。

在很多项目中，团队会给 Git commit message 加上一个类型前缀，例如：

复制代码

feat: 新增某个功能
fix: 修复某个 bug
docs: 文档变更
style: 代码格式调整（不影响功能）
refactor: 代码重构
test: 测试相关的修改
chore: 杂项任务
perf: 性能优化

其中：

表示 此次提交是对性能的优化或提升，而不是新增功能或修复 bug。

例子：

bash 复制代码

perf: 优化查询接口的响应速度

bash 复制代码

perf: 将图片压缩算法替换为更高效的实现

这种分类主要用于：

只要在提交时写 commit message：

bash 复制代码

git commit -m "perf: 缩短 API 请求的延迟"

配合项目的 commit lint、CI/CD 流程，perf 类型的提交可能会被自动识别为不影响功能，但优化性能的改动。

✅ 总结

在 Git 中的 perf主要是指 性能优化类的提交类型 ，来源于"Conventional Commits"或团队内部约定，不是 Git 原生命令。如果你在 commit 历史中看到 perf:，基本可以理解为"这次提交的主要内容是为了提高性能"。

以下是团队或社区常采用的 Git 提交类型对照表 ，基于 Conventional Commits 规范以及主流工程实践整理：

类型	全称/含义	示例	是否影响版本号（语义化版本）	典型用途
feat	feature（新功能）	`feat: 新增用户登录接口`	✅ 通常触发 minor 版本升级	增加新的功能或模块。
fix	bug fix（修复）	`fix: 修复密码验证失败的问题`	✅ 通常触发 patch 版本升级	修复缺陷、错误或逻辑问题。
docs	documentation（文档）	`docs: 更新接口说明文档`	❌	修改文档说明，不影响代码逻辑。
style	代码格式样式	`style: 调整缩进与空格`	❌	格式化或美化代码，不改变程序行为。
refactor	重构（不影响功能）	`refactor: 重构用户认证逻辑`	❌	改进代码结构或可读性，不改变功能。
perf	performance（性能优化）	`perf: 优化数据库查询效率`	❌	改善性能、降低延迟、减少资源消耗。
test	tests（测试相关）	`test: 增加接口单元测试`	❌	增加、修改或删除测试用例。
build	构建系统相关	`build: 更新 webpack 配置`	❌	修改项目构建工具、依赖或打包配置。
ci	continuous integration（持续集成）	`ci: 调整 Drone CI 构建流程`	❌	修改 CI/CD 配置或自动化脚本。
chore	杂项任务（维护性工作）	`chore: 更新 npm 依赖包版本`	❌	其他不影响代码行为的维护任务。
revert	回退提交	`revert: 回退到上一个版本`	✅（可能影响当前版本状态）	撤销先前某次提交。

在大型工程中有时还会扩展出一些类型：

标准的 Conventional Commit 格式是：

复制代码

<type>(可选scope): <简洁描述>

例如：

bash 复制代码

feat(auth): 全新 OAuth 登录功能
fix(api): 处理 GET 请求参数丢失的问题
perf(database): 优化查询索引

Scope 表示影响的模块、子系统或组件，方便快速定位变更范围。

这类规范配合自动化工具（如 commitlint , semantic-release , changelog generator , Drone CI 等）能帮助：

2026年2月12日于上海。