工作流程

Git 工作流程

我们采用 Git Flow 工作流程来管理项目开发。

分支模型

master (主分支，生产环境)
  │
  ├── develop (开发分支)
  │     │
  │     ├── feature/xxx (功能分支)
  │     ├── feature/yyy
  │     │
  │     ├── release/v1.0 (发布分支)
  │     │
  │     └── hotfix/xxx (热修复分支)
  │
  └── hotfix/xxx

分支说明

分支	用途	命名规范
`master`	生产环境代码，随时可部署	`master`
`develop`	开发分支，集成新功能	`develop`
`feature/*`	新功能开发	`feature/short-description`
`release/*`	版本发布准备	`release/v1.0.0`
`hotfix/*`	紧急修复	`hotfix/bug-description`

开发流程

1. 开始新功能

# 从 develop 分支创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/my-new-feature

2. 开发过程

# 定期提交更改
git add .
git commit -m "feat: 添加某个功能"

# 保持与 develop 同步
git fetch origin
git rebase origin/develop

3. 完成功能

# 推送到远程
git push origin feature/my-new-feature

# 创建 Pull Request 到 develop 分支

提交信息规范

我们使用 Conventional Commits 规范。

格式

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

<body>

<footer>

类型说明

类型	说明
`feat`	新功能
`fix`	Bug 修复
`docs`	文档更新
`style`	代码格式调整（不影响功能）
`refactor`	代码重构
`perf`	性能优化
`test`	测试相关
`chore`	构建过程或辅助工具的变动

示例

# 新功能
feat(robot): 添加底盘运动控制算法

# Bug 修复
fix(vision): 修复图像识别精度问题

# 文档更新
docs: 更新 API 文档

# 代码重构
refactor(control): 重构 PID 控制器

代码审查流程

审查清单

审查流程

作者创建 Pull Request
审查者 进行代码审查
审查者 提出修改意见（如有）
作者根据反馈修改
审查者 确认修改后批准
维护者 合并到目标分支

发布流程

版本号规范

使用语义化版本 (SemVer)：

主版本号.次版本号.修订号

主版本号：不兼容的 API 修改
次版本号：向下兼容的功能性新增
修订号：向下兼容的问题修正

发布步骤

从 develop 创建 release/vX.Y.Z 分支
进行版本测试和 Bug 修复
更新版本号和 CHANGELOG
合并到 master 并打标签
合并回 develop

关于我们

社区与活动

治理与安全

核心团队

贡献指南

Git 工作流程

分支模型

分支说明

开发流程

1. 开始新功能

2. 开发过程

3. 完成功能

提交信息规范

格式

类型说明

示例

代码审查流程

审查清单

审查流程

发布流程

版本号规范

发布步骤

​Git 工作流程

​分支模型

​分支说明

​开发流程

​1. 开始新功能

​2. 开发过程

​3. 完成功能

​提交信息规范

​格式

​类型说明

​示例

​代码审查流程

​审查清单

​审查流程

​发布流程

​版本号规范

​发布步骤

Git 工作流程

分支模型

分支说明

开发流程

1. 开始新功能

2. 开发过程

3. 完成功能

提交信息规范

格式

类型说明

示例

代码审查流程

审查清单

审查流程

发布流程

版本号规范

发布步骤