Skip to content

[Feature] git commit 提交规范 #9819

@supperthomas

Description

@supperthomas

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions