Skip to main content

​
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新功能
fixBug 修复
docs文档更新
style代码格式调整（不影响功能）
refactor代码重构
perf性能优化
test测试相关
chore构建过程或辅助工具的变动

​
示例

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

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

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

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

​
代码审查流程

​
审查清单

  • 代码符合项目编码规范
  • 功能正确实现
  • 有适当的单元测试
  • 文档已更新
  • 没有明显的性能问题
  • 没有安全漏洞

​
审查流程

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

​
发布流程

​
版本号规范

使用 语义化版本 (SemVer)： 
主版本号.次版本号.修订号
  • 主版本号：不兼容的 API 修改
  • 次版本号：向下兼容的功能性新增
  • 修订号：向下兼容的问题修正

​
发布步骤

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