分支命名规范
1. 主要分支类型
环境分支
- online: 线上环境分支
- uat: UAT 测试环境分支
- qa: QA 测试环境分支
功能开发分支
-
feat/ : 新功能开发
feat/功能名称feat/版本号/功能名称feat/开发者/功能名称- 示例：
feat/530/score-mall、feat/623/cps、feat/goods
修复分支
-
fix/ : 问题修复
fix/问题描述fix/环境/问题描述- 示例：
fix/cart-coupon-range、fix/online/decoration-style
发布分支
-
release/ : 版本发布
release/版本号release/日期- 示例：
release/20250613、release/v1.0.0
分支管理流程
1. 功能开发流程
graph TD
A[online/线上环境分支] --> B[创建feat/功能名称]
B --> C[功能开发]
C --> D[提交到远程分支]
D --> E[创建PR/MR]
E --> F[代码审查]
F --> G[合并到QA分支]
G --> H[QA测试]
H --> I[合并到UAT分支]
I --> J[UAT测试]
J --> K[合并到线上分支]
K --> L[发布上线]
2. 分支合并策略
开发阶段
- 本地开发: 在
feat/分支进行功能开发 - 提交规范: 使用规范化的 commit message
- 推送远程: 推送到远程仓库
测试阶段
- QA 测试: 合并到
qa分支 - UAT 测试: 合并到
uat分支 - 回归测试: 在各环境分支进行充分测试
发布阶段
- 创建版本发布分支: 从
online分支创建release/版本号分支 - 功能合并: 将所有
feat/分支合并到release分支 - 版本验证: 在
release分支进行验证和测试 - 发布上线: 验证无误后，将
release分支合并到online分支
3. 分支权限管理
保护分支
online: 只允许经过测试的代码合并uat: 需要 QA 测试通过qa: 开发完成的功能分支可直接合并
提交规范
Commit Message 格式
<type>: <subject>
tapd链接标题
提交类型
- feat: 新功能
- fix: 修复问题
- docs: 文档更新
- style: 代码格式调整
- refactor: 重构代码
- test: 测试相关
- build: 构建相关
- chore: 杂项
示例
feat: 纯积分兑换商品支持更换自提门店
--story=1006392 --user=王XX 【小程序】纯积分兑换商品支持更换自提门店 https://www.tapd.cn/xxxx/s/xxxx
分支清理策略
定期清理
- 已合并分支: 功能分支合并后及时删除
- 过期分支: 定期清理长期未使用的分支
保留策略
- 主要环境分支永久保留
- 重要的 release 分支保留
- 正在开发的功能分支保留
冲突解决
预防冲突
- 及时同步: 定期从主分支拉取最新代码
- 小步提交: 避免大范围修改
- 沟通协调: 团队成员间及时沟通
解决冲突
- 本地解决: 在本地分支解决冲突
- 测试验证: 解决冲突后进行充分测试
- 重新提交: 确认无误后重新提交
最佳实践
1. 分支命名
- 使用有意义的分支名称
- 包含功能或问题描述
- 遵循团队约定的命名规范
2. 开发流程
- 从最新的主分支创建功能分支
- 保持分支的单一职责
- 及时合并和删除已完成的分支
3. 代码审查
- 所有代码都需要经过审查
- 重要功能需要多人审查
- 审查重点关注代码质量和业务逻辑
4. 测试验证
- 每个环境都需要充分测试
- 自动化测试和人工测试结合
- 回归测试确保功能完整性
应急处理
热修复流程
- 创建 hotfix 分支: 从 online 分支创建
- 快速修复: 最小化修改范围
- 紧急测试: 快速验证修复效果
- 紧急发布: 直接合并到生产分支
- 同步更新: 将修复同步到其他分支
回滚策略
- 代码回滚: 使用 git revert 回滚有问题的提交
- 版本回滚: 回滚到上一个稳定的 release 版本
