现有分支：
dev-1.2.1
main
dev-1.2.2
pretest-1.2.2
develop
test
目前情况：dev-1.2.1已上线，已合并到main分支。
（一） 从dev-1.2.1分支上创建dev-1.2.2分支作为1.2.2迭代需求版本的基础分支。
（二）从dev-1.2.2分支上传创建pretest-1.2.2分支作为多个需求开发的合并分支。
新增的多个需求，每个需求都以dev-1.2.2分支为基础创建，开发完成后合并到pretest-1.2.2汇总， pretest-1.2.2为当前开发中最新的汇总分支，随时可以把该分支合并到develop分支部署开发环境联调接口，也可以合并到test分支部署测试环境进行测试。
（三）pretest-1.2.2分支合并到test分支测试，测试完成后，pretest-1.2.2分支合并到dev-1.2.2分支，由dev-1.2.2分支合并到main分支部署正式环境。
（四）pretest-1.2.2分支合并到test分支测试，测试出现的bug，从pretest-1.2.2创建bug分支修改bug，修复bug后合并到pretest-1.2.2分支，pretest-1.2.2分支合并到test分支测试进行复测。bug复测完没问题后毕重复（三）的流程。
遇到问题及解决方案：
遇到问题：
如果在开发过程中，某几个需求需要提前上线。
解决方案：
在dev-1.2.2上创建instancy-1.2.2分支，这几个需求在各自分支上开发完成后，合并到instancy-1.2.2分支，由instancy-1.2.2分支合并到develop分支部署开发环境联调接口，由instancy-1.2.2分支合并到test分支部署测试环境进行测试，测试阶段完成后由instancy-1.2.2合并到dev-1.2.2，dev-1.2.2合并到main分支，发布正式环境。剩余几个分支分别从dev-1.2.2分支拉取最新代码。继续剩余分支的开发。后续仍然走各自分支合并到pretest-1.2.2分支，pretest-1.2.2分支合并到develop，pretest-1.2.2分支合并到test分支，pretest-1.2.2合并到dev-1.2.2，dev-1.2.2合并到main部署正式环境的流程。
在上述过程中各自的分支仍是以原始分支dev-1.2.2为基础，并没有从pretest-1.2.2分支主动拉取其他分支提交的代码，如果两个分支相互关联，可以两个分支之间相互合并。然后合并到pretest-1.2.2分支。
这样做法优点是有一个最新的公共分支来合到develop和test分支，冲突会在开发过程中进行解决，而不是各个分支在上线时才合并如果发现有冲突，上线前还要解决冲突。
在实际开发中一般可以这样更简单的操作。
实际用到的分支：
main
dev-1.2.2
develop
test
feat/a
feat/b
feat/c
其中feat/a，feat/b，feat/c分别为要开发的新需求，仍是遇到以上问题，a，b两个分支需要提前上线，此时需要做的是开发完成的a，b分支分别合并到develop分支部署开发环境联调接口，联调结束后，a，b分别合并到test分支部署测试环境进行测试。测试出的bug在各自的a，b分支修复后分别合并到test分支测试。复测完毕，feat/a，feat/b分别合并到dev-1.2.2，dev-1.2.2合并到main部署正式环境的流程。
如果a，b分支的业务有交叉，在线上合并develop时会出现冲突，此时关闭合并请求，在本地拉取最新的develop代码。在develop创建一个新分支develop-conflict，把a，b合并到develop-conflict，在develop-conflict分支上解决冲突，解决冲突后把develop-conflict合并到develop，走正常流程。虽然test分支代码和develop是一致的，但是环境配置不一样不能讲develop下创建的分支不能直接合并到test，所以在test分支下创建test-conflict重复以上操作。后续的联调和测试的bug在a，b各自的分支修改。后续在合并到develop和test上时就不会再有冲突了。develop-conflict、test-conflict可以删除了。
—END—