Skip to content

contribute.md

Latest commit

 

History

History
126 lines (83 loc) · 2.9 KB

contribute.md

File metadata and controls

126 lines (83 loc) · 2.9 KB
layout default
title 贡献指南
nav_order 5

Git提交规范

提交信息结构

标准的 Git 提交信息通常包含三部分：

  • 标题（Header）:简明描述本次提交的目的，建议不超过50个字符。
  • 正文（Body）:详细说明本次提交的背景、目的和影响（可选）。
  • 页脚（Footer）:关联的issue、breaking change等说明（可选）。

常用提交类型（Type）

为了让提交信息更易读、自动化工具更好地识别，常见的提交类型有：

  • feat：新功能（feature）
  • fix：修复bug
  • docs：文档变更
  • style：代码格式（不影响功能，如空格、分号等）
  • refactor：重构（即不是新增功能，也不是修复bug的代码变动）
  • test：增加或修改测试代码
  • chore：构建过程或辅助工具的变动
  • perf：性能优化
  • ci：持续集成相关配置修改

格式:

<type>(<scope>): <subject>

<body>

<footer>

例子:

feat(user): 增加用户注册功能

用户可以通过邮箱注册新账号，添加了相关接口和前端页面。

Closes #12

版本管理规范

版本号规范

采用语义化版本号（Semantic Versioning，简称 SemVer）进行管理，格式为：<主版本号.次版本号.修订号>，例如：1.2.3

  • 主版本号（Major）：有不兼容的 API 修改时，递增
  • 次版本号（Minor）：新增功能，且兼容旧版本时，递增
  • 修订号（Patch）：修复 bug，且兼容旧版本时，递增

发版流程

准备发布内容

  • 确认所有待发布的功能/修复已合并到主分支（master）
  • 检查并完善文档、变更日志（CHANGELOG.md）

更新版本号

按照语义化版本规则，修改项目中的版本号

编写变更日志

在 CHANGELOG.md 文件中记录本次版本的新增、修复、变更等内容

创建 Tag 与 Release

使用 Git 创建 Tag，例如：

git tag v1.2.3
git push origin v1.2.3

在 GitHub/GitLab 等平台创建 Release，填写版本说明

构建与发布

如果有构建产物，完成构建并上传至 Release。若有包管理平台，同步发布新版包

发版注意事项

  • 保证所有测试通过，CI/CD 无异常
  • 文档与代码保持同步更新
  • 明确版本兼容性，必要时提醒用户升级须知

分支管理规范

  • 主分支（main/master）：始终保持可发布状态
  • 开发分支（develop）：日常开发，合并到主分支后发版
  • 特性分支（feature/xxx）：新功能开发
  • 修复分支（fix/xxx）：bug 修复
  • 发布分支（release/xxx）：准备发版时创建，合并后打 tag

变更日志规范

变更日志建议包含如下内容：

  • 新增（Added）
  • 修复（Fixed）
  • 变更（Changed）
  • 移除（Removed）

例如：

## [1.2.3] - 2024-06-01
### Added
- 新增用户登录功能

### Fixed
- 修复注册页面崩溃问题

### Changed
- 优化首页加载速度