-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Description
Describe problem solved by the proposed feature
计划添加一个feature,验证git commit的内容,检查内容符合规范的git commit的rule则提交,不符合则展现提示,要求规范提交git commit信息。这个目前先提issue进入讨论环境,欢迎大家提建议。添加这个rule之后,git commit的内容需要规范提交,请问大家是否愿意符合该rule,愿意符合的下面commit +1, 如果有更好的建议的,可以comment
https://supperthomas-wiki.readthedocs.io/00_supperthomas/12_gitflow/gitcommit.html
https://www.conventionalcommits.org/
Describe your preferred solution
https://www.conventionalcommits.org/zh-hans/v1.0.0/
提交说明包含了下面的结构化元素,以向类库使用者表明其意图:
fix: 类型 为 fix 的提交表示在代码库中修复了一个 bug(这和语义化版本中的 PATCH 相对应)。
feat: 类型 为 feat 的提交表示在代码库中新增了一个功能(这和语义化版本中的 MINOR 相对应)。
BREAKING CHANGE: 在脚注中包含 BREAKING CHANGE: 或 <类型>(范围) 后面有一个 ! 的提交,表示引入了破坏性 API 变更(这和语义化版本中的 MAJOR 相对应)。 破坏性变更可以是任意 类型 提交的一部分。
除 fix: 和 feat: 之外,也可以使用其它提交 类型 ,例如 @commitlint/config-conventional(基于 Angular 约定)中推荐的 build:、chore:、 ci:、docs:、style:、refactor:、perf:、test:,等等。
build: 用于修改项目构建系统,例如修改依赖库、外部接口或者升级 Node 版本等;
chore: 用于对非业务性代码进行修改,例如修改构建流程或者工具配置等;
ci: 用于修改持续集成流程,例如修改 Travis、Jenkins 等工作流配置;
docs: 用于修改文档,例如修改 README 文件、API 文档等;
style: 用于修改代码的样式,例如调整缩进、空格、空行等;
refactor: 用于重构代码,例如修改代码结构、变量名、函数名等但不修改功能逻辑;
perf: 用于优化性能,例如提升代码的性能、减少内存占用等;
test: 用于修改测试用例,例如添加、删除、修改代码的测试用例等。
脚注中除了 BREAKING CHANGE: ,其它条目应该采用类似 git trailer format 这样的惯例。
Describe possible alternatives
No response