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