Git Commit
按 Conventional Commits 规范生成提交。
单次提交
一次调用只产生一个 commit,不拆分。 即使改动跨了多个 type,也全部归入这一个提交:
- type 取主要改动;为它服务的前置配置、依赖、文档与测试都是配套产物,不单独成 commit
- 改动点多时靠 body 逐条说明,不靠拆 commit
Type 选择
根据变更内容选择对应前缀,不要凭直觉混用:
| type | 使用场景 |
|---|---|
feat |
新增功能、新增页面 / 组件 / API endpoint / 配置项 |
fix |
修复 bug、修正错误行为、修正错误的类型 / 校验逻辑 |
refactor |
重构:不改变外部行为,也不修 bug,不加功能(如重命名、抽函数、调整结构) |
perf |
性能优化(包括渲染优化、减少请求、缓存策略等) |
style |
仅代码格式:缩进、空格、换行、引号、删除未用 import、调整 import 顺序 |
docs |
文档与注释:README、JSDoc、代码注释;不含可执行代码改动 |
test |
仅测试代码:新增 / 修改 / 删除测试用例、调整测试配置 |
build |
构建系统:打包配置、依赖增删升级 |
ci |
CI / CD:工作流、流水线脚本、发布配置 |
chore |
杂项:脚手架、IDE 配置、忽略文件、不影响生产代码的工程化调整 |
revert |
回滚先前的提交 |
容易混淆的边界
- 同时改逻辑和格式 → 按主要改动归类,纯格式部分让步
- 修 bug 顺便重构 →
fix(bug 修复优先级更高) - 新增功能附带测试 →
feat(测试是配套产物) - 改文档里的代码示例 →
docs - 升级依赖导致的代码适配 →
build - 配置项新增(影响运行行为)→
feat;仅工具配置 →chore - 说明本次改动的文档 → 跟随该改动的 type;独立的文档整理才是
docs
Scope 选择
- 优先使用受影响的包 / 模块名
- 单包内改动可用更细粒度的子模块名
- 跨包或难以归类时省略 scope
严格格式
<type>(<scope>): <subject>
[optional body]
- subject:祈使句、首字母小写、≤ 72 字符、句末不加标点;概括整体意图,细节留给 body
- body 在 subject 说不清"为什么"、或改动点需分别交代时写,每行 ≤ 72 字符
- 多个改动点用
-逐条列出,一条一件事,按重要性排序 - 提交信息语言与仓库历史保持一致
- 通过 HEREDOC 传递 message,保留换行