git的提交规范
1. 规范
1.1 基本的 commit 信息格式
一个常见的提交信息格式通常包括以下几个部分:
- 类型(type): 描述提交的类别,比如是新功能、修复、文档等。
- 范围(scope): 可选,描述提交影响的范围,比如是某个模块、功能等。
- 主题(subject): 简短的描述提交的目的。
- 正文(body): 可选,详细描述提交的内容、动机等。
- 页脚(footer): 可选,通常用于关闭某个 issue 或者添加破坏性变更的说明。
1.2 常见的类型(type)
“这个提交是否值得出现在最终的发行版上线日志(CHANGELOG)里?”
- 如果是,那它很可能是 feat 或 fix。
- 如果否,那它更可能是 refactor, style, chore 等其他类型。
feat: 新功能 (feature)
- 判断标准: 这次提交是否增加了代码库的新能力?
- feat: 实现网站的暗黑模式切换
fix: 修复 bug
- 判断标准: 这次提交是否修正了一个不正确的行为?
- fix:解决 Safari 浏览器下日期显示不正确的问题
refactor: 代码重构(既不是新增功能,也不是修复 bug)
- 判断标准: 用户或测试人员感觉不到任何变化,但代码变得更“好”了(更清晰、更高效、更易于扩展)。
- refactor:移除重复的代码块,抽象成一个通用函数
docs: 文档修改
- 判断标准: 只改动了
.md
文件或代码里的注释。 - docs: 更新 README,补充项目本地启动步骤
- 判断标准: 只改动了
style: 代码格式修改(不影响代码逻辑,如空格、分号等)
- 判断标准: 由 Prettier、ESLint 等格式化工具自动生成的改动,或者手动调整了代码外观。
- style: 移除多余的空行和未使用的 import 语句
test: 增加或修改测试
- 判断标准: 只修改了测试文件(如
*.test.js
,*.spec.js
)或测试配置文件。 - test(login): 为登录成功和失败的场景添加单元测试
- 判断标准: 只修改了测试文件(如
perf: 性能优化
revert: 回滚某个先前的提交
build: 修改构建系统或外部依赖(如 a.js、npm)
- 判断标准: 是否修改了
package.json
、webpack.config.js
、vite.config.js
、pom.xml
这类文件? - build(deps): 添加axios库用于网络请求
- 判断标准: 是否修改了
ci: 修改 CI/CD 配置文件和脚本
- 判断标准: 是否修改了 .github/workflows/、.travis.yml、Dockerfile 这类文件?
- ci: 优化 Docker 镜像构建,减少镜像大小
chore: 其他不修改源码或测试的提交(杂项,其他不属于以上任何类型的琐碎修改,通常是辅助性的工具或配置改动。)
- 判断标准: “家务活”,不修改源代码、不修改测试、不修改构建和CI,但又是必要的改动。
- chore: 更新 .gitignore 文件,忽略 .env 本地配置文件
1.3 示例
1 | git commit -m "feat(auth): add login functionality" |
2. 规范工具
2.1 cz ai
1 | npm install -g cz-git commitizen |
2.2 aicommit
原理是 git diff 结果,交给open ai,感觉太费钱。
1 | npm install -g aicommits |