版本划分
develop：开发版，连接开发服务器，测试维护
release-年月日：内部试用版，连接内部试用服务器，运营维护
master：正式版，连接正式服务器，运营维护
tag-年月日，用来方便产线版本追述
基本流程
开发测试在develop进行开发、测试、解bug、验证
开发测试完成之后，进行一次内部发布，产出是“release-年月日”
运营对“release-年月日”进行内部试用，这个阶段出现的bug直接在这个分支上修改和验证
“release-年月日”验证完成后，可以根据情况决定是否对外发布。比如苹果iOS系统的对外发布频率是一年一次。不过其内部发布频率应该高于这个频率
需要对外发布的“release-年月日”转移到master，进行对外发布，同时打好相应的tag
如果线上版本发现bug，直接从master拉出相应的hotfix分支，进行修复、验证和打补丁
开发版
主体分支是develop
进行新特性开发，可以拉分支develop-taskxxx，完成后合并到develop。当然，根据具体情况，也可以不合并。
进行bug修复，可以拉分支develop-bugxxx，完成后合并到develop。当然，根据具体情况，也可以不合并。
测试以develop这个分支为测试对象。当然，如果需要，对单独的任务develop-taskxxx，bug修复develop-bugxxx，也是可以的
连接开发环境，由测试负责维护、配置
测试验证完成后，为了保证稳定，develop分支可以有“封板期”
合并到develop之后，可以把分支develop-taskxxx，develop-bugxxx删除。当然，根据实际需要，也可以保留一段时间。
内部验证版
- 主体分支是“release-年月日”
- 一种方式是统一用“release”，然后用tag的方式做标记。不过这里有一种隐含意味是“只有一个内部验证版”，无法体现苹果那种“多次内部发布，一次对外发布”的情况
- 每一个“release-年月日”，都是一个实际可以对外发布的“可用版本”，是否对外发布，取决于运营决策
- 对于重大节点，比如“阿里的双11”，需要提前开发，内部验证好，至于正式对外发布，则要等到相应的时机。
- 版本规划和开发，一般要提前于实际需求，这样才能做到“不打无准备之战”
- 还有一种命名方式是“release-月日”，不带“年”信息，在跨年的时候可能会带来困扰，当然也隐含“版本只保留1年，超过1年的版本将清理的意思”。在大多数情况下，这样做也是合理的。
连接内部验证环境，由运营负责维护、配置
如果发现bug，可以拉分支“release-年月日-bugxxx”，开发完成和测试验证之后，合并到“release-年月日”
对于需求变更，原则上不予执行。如果特殊需要，可以拉分支“release-年月日-taskxxx”，开发完成和测试验证之后，合并到“release-年月日”
经过验证，并且运行稳定之后，根据需要将“release-年月日-bugxxx”，“release-年月日-taskxxx”的改动合并到develop分支（此时的develop可能已经领先很多，需要做增量合并），保证develop内容最新。当然，根据实际情况，也可以不合并。
合并到“release-年月日”之后，可以删除相应的“release-年月日-bugxxx”，“release-年月日-taskxxx”。当然，也可以根据需要，保留一定的时间。
“release-年月日”作为develop和master之间的缓冲，将开发版和正式版解耦。需要有专人进行管理和维护。
正式版
主体分支是master
连接正式环境，由运营负责维护、配置
master由“release-年月日”合并而来，合并之后，拉“tag-年月日”，这个年月日和“release-年月日”中的年月日一致。（并不是每个release都会到master的）
“release-年月日”合并到master之后，“release-年月日”可以删除，因为已经转换为“tag-年月日”；当然“release-年月日”保留一定时间，比如半年，也是有一定道理的。如何取舍，看具体的管理方式。
如果发现bug，可以拉分支“hotfix-年月日”
“hotfix-年月日”开发验证完成后，合并到master，保证master稳定可用
“hotfix-年月日”开发验证完成后，其改动合并到develop（此时的develop可能已经领先很多，需要做增量合并），保持develop最新可靠。当然，根据具体情况，可以不合并
“hotfix-年月日”合并到master之后，同样打“tag-年月日”
“hotfix-年月日”在合并之后可以删除。当然，也可以根据需要，保留一定的时间。
