组织介绍

一、项目

• 一天一句毒鸡汤小程序
• 一天一句毒鸡汤鸿蒙元服务
• 多肉柠檬官网
• 多肉柠檬后台管理中心
• 多肉柠檬服务
• 天天领券中心

二、仓库命名

英文单词之间用中划线-隔开,最后下划线_分割,加上哪个端
例如:

• 小程序:chicken-soup_miniapp
• 官网:chicken-soup_site
• 服务端: chicken-soup_server
• 鸿蒙:chicken-soup_harmory

三、版本号控制规则

SemVer 规范详解

• 主版本号(MAJOR):
  当你做了不兼容的 API 修改时,应当增加主版本号,并重置次版本号和补丁版本号为零(0)。例如,从 1.2.3 变为 2.0.0。
• 次版本号(MINOR):
  当你增加了向后兼容的功能时,应当增加次版本号,并重置补丁版本号为零(0)。例如,从 1.2.3 变为 1.3.0。
• 补丁版本号(PATCH):
  当你做了向后兼容的 bug 修复时,应当增加补丁版本号。例如,从 1.2.3 变为 1.2.4。
• 预发布版本(Pre-release):
  在正式发布前,你可以使用 - 符号来指定预发布版本,例如 1.2.0-alpha 或 1.2.0-beta.2。
• 构建元数据(Build Metadata):
  构建元数据用于构建信息,对版本的实际使用无意义,可以使用 + 符号来指定,例如 1.2.0+build.11.e0f985a。

示例

• 正式版本:V1.1.0 表示这是一个稳定的版本,没有任何预发布标签。
• 带有预发布版本:V1.1.0-alpha 表示这是一个 alpha 版本。
• 带有构建元数据:V1.1.0+build.11.e0f985a 表示这是一个带有特定构建信息的版本。

实际应用

在实际应用中,版本号控制规则可以根据项目的需要进行调整。例如:

• 如果项目初期变化较大,可以频繁更新主版本号(大版本更新,界面换新,大功能上线等)。
• 如果项目趋于稳定,主要增加次版本号和补丁版本号。
  1. 次版本号:(较小改动, 小功能上线)
  2. 补丁版本号:(问题修复,线上功能热修复等)
• 对于内部版本或测试版本,可以使用预发布版本来标识。

四.git代码提交规范

1. 基本格式
   一个标准的提交信息通常包含三个部分:类型(Type)、范围(Scope)和描述(Subject)。格式如下:
   <type>(<scope>): <subject>

2. 类型(Type)
   feat - 新功能(feature)
   fix - 修复bug
   docs - 文档更新
   style - 格式调整,不影响代码运行(如空格、缩进、缺少分号等)
   refactor - 重构(即不是新增功能也不是修复bug的代码变动)
   perf - 性能优化
   test - 增加测试用例
   chore - 构建过程或辅助工具的变动
   ci - 持续集成相关配置文件的修改
   build - 影响构建系统或外部依赖关系的变更
   revert - 回滚到之前的版本

3. 范围(Scope)
   范围部分是可选的,用于指明此次提交影响的模块或组件。例如,如果你在一个名为user的模块中添加了一个新特性,可以写成feat(user): add login feature。

4. 描述(Subject)
   描述部分应该简洁明了地说明此次提交的主要目的。首字母不需要大写,结尾不加句号。尽量控制在50个字符以内。

5. 长描述(Body, 可选)
   如果需要提供更多的上下文信息或解释为什么做出这样的改变,可以在主体部分详细描述。每个段落不超过72个字符。

6. 脚注(Footer, 可选)
   脚注部分主要用于引用解决的问题编号,如Fixes #123,或者在回滚更改时指明原提交,如Revert "feat: add blue button"

示例
fix(user): correct minor typo in username validation 修改了用户名验证中的小错误,确保用户输入至少4个字符长。

刘贵生