参与协作

commit message

需要遵循以下格式:

更新类型(更新模块):(可选)(版本号) (更新概括):

- [(可选)子更新类型]更新内容1
- [(可选)子更新类型]更新内容2
- ...

更新类型有这些内容:

类型	说明
✅feat	新功能
🔧modify	修改功能
🐛fix	修bug
⚒️refactor	重构
📃docs	改文档，比如README
❇️style	改代码风格，不影响功能
🔎test	加测试、改测试
📆chore	杂项，比如改.gitignore
⏫perf	性能优化
🛒ci	CI/CD相关改动
🚅build	改构建系统或依赖
◀️revert	回滚
🔡dependency	依赖更新
❌remove	删除弃用的组件
↪️move	移动了组件
❓unknown	未知类型
自定义	尽量以一个直观的英文单词描述，最好配上emoji

内容较多时需要对更新内容添加更新类型提示

分支

请按此图所示的分支结构来更新：

创建的分支需要以feature/开头，以表示功能分支，或创建一个fork，并在fork的分支开发。

发布pr时要选择合并到develop分支。

版本号

clickmouse版本格式为：A.B.C.D[(alpha | beta |.dev | rc) E]

正式版本

正式版不带.dev、alpha、beta或rc后缀。

A位代表有重大更新，有代码级的变动。如1.0升级到2.0就重构了代码。

B位代表有普通更新，通常是更新一些大功能。

C位代表有修复更新，通常会更新一些小功能和一些bug。

D位代表版本代号，通常每A, B, C位有变动时候+1。也有可能A, B, C位没有变动，D位+1，这代表紧急更新，通常是修复几个重大影响的bug。

测试版本

测试版本带.dev、alpha、beta或rc后缀。

通常前面的A.B.C.D在一个测试周期内不变，代表下一个版本。

.dev代表早期开发更新，功能不稳定，bug很多，位于版本项目初期。这阶段新增的功能将会被放到实验室中，并默认关闭。

alpha代表晚期开发更新，功能不完善，bug较多，位于版本项目早期。这阶段新增的功能将会被放到实验室中，并默认关闭。

beta代表发布测试更新，功能完善，bug较少，不会再新增功能，位于版本项目中期，并且会逐步合并实验室中的feature。

rc代表预备发布版本，功能完善，bug较少，会修复一些重要安全问题或bug，最接近正式版，即将发布正式版，位于版本项目末期。

issue

• 标题格式：[类型] 标题等，可以随便写，但要准确描述更新内容。
• 内容应准确写出你的需求，并选择性给出解决方案，上传截图，添加附加信息（如clickmouse版本号）
• 类型为bug、enhancement、question等。
• 我们给了一些模板，可直接使用。
• 使用labels来标记issue的类型，比如bug、enhancement、question等。
• 设置issue的milestone为你想应用的issue版本。
• 安全问题请见安全说明文档。

pr

• 标题格式：[类型] 标题
• 使用labels来标记pr的类型，比如bug、enhancement、question等。
• 关联issue，这样我们就可以知道这个pr解决了哪个issue。
• 需要准确写出更新内容，关联到版本号的milestone。
• 可选添加实现思路

规范

我们pr合并的顺序为：

pr无特定格式，但是必须清晰描述更新内容，关联到版本号的milestone；标题要简略描述更新内容，若修复或添加了issue里的建议，把该issue编号写进该行为，若出现多个重复issue，则只用写一个，并简单描述此bug。

快车pr

警告

快车pr请谨慎使用

• 快车pr的意思是跳过部分正常的pr合并分支步骤，以更快的合并到目标分支的功能。
• 标题格式：[✈️快车] 标题
• 使用快车必须在pr描述中说明使用的原因

如果有人快车合并，但没写快车合并的原因，则拒绝合并该人的分支。

快车pr有高优先级，会优先进行处理。

milestone

• 我们给每个版本都设置了一个milestone，用来管理该版本的issue和pr。
• 需要每个issue或pr都关联到一个milestone，这样我们才能知道该issue或pr是否在下个版本中添加。
• milestone格式为:dev_版本号