问答 各位测试大佬们，想了解下研发提测方式
目前了解到的提测方式有以下几种：
1.基于 master 分支拉出需求分支，进行开发和测试，待测试完成合入 master 分支，再拉 release 分支
2.基于 master 分支拉出需求分支，开发完成后，合入 test 分支，测试基于 test 分支测试，测试完成后再合入 master 分支，再拉 release 分支
3.基于 master 分支拉出需求分支，先拉 release 分支，将需求分支合并到 release 分支，测试所有需求基于 release 分支进行测试
第一种方式，因为是分支提测，每个分支需要一个测试环境，会导致测试环境不够用的情况
第二种方式，仅需一个测试环境，但是当期需求如果修改的文件耦合严重的话，解决冲突很痛苦
第三种方式，因为需求合到 release 分支，会存在需求必须测试完成，迭代才能关闭的情况
以上三种方式有好有坏，想了解下各位大佬公司的提测方式如何
看团队情况吧, 目前接的比较多是第 2 种. 以 tag 的方式标记并出包待测试内容.
我们人数 30+ 的小团队，做手游，说下我们的流程。
项目初期，我们需求研发、测试都是基于 master 版本，不拉需求和 release 分支，直接打 master 版本手机包看效果，第一是测试需求少，另一方面需求变动也大，我们就没做其它分支版本。一直持续到项目研发中后期，确定上线时间节点，假如还有 2 个月项目上线，利用 1 个月的时间将现有功能在 master 版本再测一遍，修复解决后拉 release 分支版本然后 release 版本交叉再测一遍，此后新需求都会经过 master 和 release 两个版本测试，只同步相关代码、表格、资源等，不再单独出版本。
我们是基于 master 分支拉取开发和测试使用的分支，分支部署 beta 环境后生成一个镜像 tag，最后测试通过后使用镜像 tag 发布线上，并且将代码合并到 master 分支
首先要处理研发的开发分支管理。再就是结合公司测试的情况，决定的使用哪种方式。
题外话，站在公司的角度，为了省钱，会选择只有一个测试环境的方式。