[Feature] git commit 提交规范

[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

[unicornx]

支持，只是建议 rule 不要太复杂，引入额外太多的管理成本就不容易推广。

这个是我个人的一些经验总结，供参考：https://github.com/plctlab/plct-rt-thread/blob/notes/0.notes/20241212-github-tips.md#1-%E5%A6%82%E4%BD%95%E7%BC%96%E5%86%99-git-commit-message

[a1012112796]

我个人认为意义不大，毕竟 github 支持使用压缩提交的方式合并 PR。十分推荐优先使用这种方式，因为可以在合并的时候，由管理员编写最终合并到主分支的那唯一一次 commit 记录。默认使用的是 PR 的标题和描述，也是可以实时修改的。

[a1012112796]

另外其实已经有一个规范了 https://github.com/RT-Thread/rtthread-specification/blob/master/git_pr.md ， 不过用的是 [].