多团队git协同开发流程
一、版本管理的挑战
虽然有这么优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：
- 如何开始一个Feature的开发，而不影响别的Feature？
- 由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？
- 哪些分支已经合并回了主干？
- 如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？
-
线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release?
二、基于Git Flow扩展的多开发团队分支协同
file
常用的分支：
• Production 分支
也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
• Develop 分支
这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
• Test 分支
这个分支主要是用来对应每个测试环境打包，构建镜像
• Personal分支
开发人员基于主开发分支创建的自己提交代码的分支
三、分支管理
• 初始化分支、拉取Develop主分支
所有在Master分支上的Commit应该Tag
file
项目立项时，申请开通对应版本的开发主分支，命名规则：vx.xx.xxx
• 开发阶段
所有参与版本开发人员从主开发分支拉取自己的personal开发分支，命名规则：v.x.xx.xxx-开发人员姓名小写全拼，（一般版本迭代开发完成，该分支可以删除销毁，避免代码库中分支过多）
file
• 测试阶段
1、开发人员完成功能开发并自测完成可以申请合并到测试分支，部署到测试环境
file
2、测试人员在测试环境上，覆盖测试用例，发现bug并提交给开发人员进行bug修复
3、开发人员完成bug修复，并将代码合并到测试分支，部署到测试环境进行回归测试
• 产品验收阶段
file
四、多团队协作开发
file
严格按照版本迭代的先后顺序进行代码更新合并操作，原则上尽量减少冲突。
五、线上bug紧急修复
file
线上紧急bug修复，直接从主干分支上拉取最新版本代码，命名规则：bug-yyyymmdd-问题描述。
六、完成版协作流程图
file
本文由博客一文多发平台 OpenWrite 发布！
网友评论