我们开发团队的敏捷git工作流
现状
我们开发团队目前拥有30名左右的开发人员，其中前端大概有8名，前端项目大大小小几十个，几乎每天都有在发版的项目。 我们的项目有4套线上环境：生产环境，预发布环境，测试环境，开发环境。以及拥有一些不固定的特性环境，用于特性测试。
对于拥有多环境我们团队的git工作流是怎么样的？
git工作流
我们的团队发布gitflow和你们可能有些许不一样，这个我觉得没有标准，适合自己团队就行，我们的团队项目的分支划定有：
- master，主分支，只用于线上现网环境发布
- develop，开发分支，只用于线上开发环境发布
- test，测试分支，只用于线上测试环境发布
- feature，特性分支，用于本地开发新功能
- bugfix，修复分支，用于本地修复bug
在我们的工作流中，通常一个功能开发/bug修复从开始到结束是这个样子的
从代码分支的角度来看他的流程如下：
从Master创建feature/bugfix分支
首先从master分支创建feature分支或者bugfix分支，在本地进行开发，本地调试。
git checkout master
git checkout -b feature/xxxxxx
#或者
git checkout -b bugfix/xxxxxx开发的过程中合入Develop，用于和其他人员联调、集成测试
开发过程中可能需要发布到一个线上环境中方便集成测试或者方便后端人员调试自己的接口问题，这个时候需要将feature分支合入develop分支， 并发布到线上的开发环境，这个环境通常会频繁的发布，合入代码，并且此环境只有开发人员才会使用。
git checkout develop
git merge feature/xxxxxx
git push合入Test分支，测试人员介入测试
当开发任务自测结束之后，要让产品人员验收、测试人员介入测试，这时候就要把feature分支合入test分支中，发布到线上的测试环境，这个环境不会频繁的 发布，只有当某一个功能完结之后才会合入到test分支，此环境主要用于产品人员、测试人员使用。
git checkout test
git merge feature/xxxxxx
git push合并入Master分支，发布到预发布环境
当产品验收通过、测试人员测试通过之后，就可以将feature分支合入master分支，发布到预发布环境，此时测试人员会再次验证预发布环境使用生产数据的情况下是否功能正常
master分支不允许本地推送，需要去提交merge request，由专人CR代码，通过之后才能合入master
发布生产环境
确认正常之后，将master代码发布到生产环境，至此一个功能开发完成。此时给master分支打tag, 便于回溯问题、版本回滚等操作。
git checkout master
git pull
git tag release-xxxxxx优势
这一套gitflow流程，在我们团队中运行了很久，只要保持流向是单向的，就不会有难以解决的冲突， 目前来看，这套流程还是挺适合我们团队的，结合一些CI/CD使用起来非常高效， test、dev分支推送自动编译、发布对应环境，合入master之后会自动发布到预发布环境，然后确认之后，手动通过才会发布到生产环境中。
环境的划分可以给到不同的团队角色稳定的使用环境，互不干扰，互不影响，开发人员可以专注开发，测试人员可以专注测试，产品人员可以专注验收。
问题
存在的一个最大的问题是如下场景
- feature/a 今天要发布
- feature/b 今天也要发布
如果：
- feature/a先合入master，发布到预发布环境中
- 然后10分钟后，feature/b合入master，也在预发布环境中 他们都在预发布环境中等待验证/确认，但是feature/b先验证完，feature/b手动审核通过，发布到生产环境，此时存在的问题：
- feature/a还在预发布环境验证的特性，一并被发布到生产环境。
如果这个时候feature/a特性分支预发布环境中验证完成，手动通过审核，发布到生产环境，此时又出现了新的问题：
- feature/b的特性被退回了
这个问题目前只通过发布排期、人为控制来规避，CI/CD自动化增加检测逻辑，排队发布，但是始终无法解决需求排队的本身，前面需求没发布之前，后面的始终不能发布。
最后
每个团队的工作流都有是自己摸索出来的，不一定适合所有团队，因为团队的规模、人员素质、项目类型都有独特的需求，曾经svn时代，我们的团队也干过 拉个分支，开发完了就直接往master合的事儿，这个还是应该避免，越规范的流程，虽然麻烦，但是可以规避一些风险，但是越强的规范会导致工作量、灵活度变低， 需要自行取舍。
