Git Flow 工作流

简要介绍

branch为主，tag为辅

1. 两个常驻分支：master、dev
2. 无数个版本分支：feature/1.0、feature/2.0、feature/3.0……
3. 禁止直接在master、dev分支上开发
4. 每一次合并到dev分支视为一次提交测试
5. 每一次合并到master分支视为一次上架，每次上架均应打上tag
6. 开发人员无权操作master分支，由测试人员负责master分支的维护
7. 每个版本有两位数字，第一位数字是产品版本，由产品决定（例如1.0），第二位数字是BUG修复版本，有测试决定（例如1.1）

项目搭建阶段

项目初始化

1. 新建master、dev分支，其中，master分支用于发布正式版（上架用），dev发布测试版（提交测试用）
2. 新建版本开发分支：feature/1.0分支，在此开支上开发该版本功能，禁止直接在master、dev分支上开发

项目开发阶段

以feature/1.0为例

1. 每完成版本开发分支（例如feature/1.0）上的一个需求点，都可以合并到dev上，每一次合并，视为一次提交测试（后续可考虑加入jenkins持续集成，每一次合并到dev分支，会自动编译成测试包，并自动上传到蒲公英，并自动给测试人员发送邮件通知）
2. 该版本开发分支（例如feature/1.0）的所有需求点开发完成后，且均以合并到dev分支上了，且均通过测试了，由测试人员决定是否合并到master分支上，并加上版本tag（例如1.0），每一次合并到master上，视为一次上架（后续可考虑加入jenkins持续集成，每一次合并到master分支，会自动编译成正式包，并自动上传到官网，并自动给项目组所有人员发送邮件通知）

项目迭代阶段

以feature/1.0迭代到feature/2.0为例

1. feature/1.0的分支继续保留，在dev分支上切出feature/2.0分支，新的版本需求都在feature/2.0上开发
2. 如果在feature/2.0分支的开发过程中，有feature/1.0的BUG提交上来，切换到feature/1.0的分支上修复BUG，BUG修复后合并到dev分支上提交测试，测试完后后由测试合并到master，会加上新的修复版本tag（例如1.1）

其余说明

1. 随着版本迭代次数的增加，当迭代了很多个产品版本之后，可能分支数量太多，难以管理，此时，可以删除已经不活跃的分支，一般来说，保留前2个产品版本分支即可（例如开发到9.0时，可以删除1.0到6.0的分支）
2. 被删除后的版本分支，并非不可回溯了，因为我们每一次上架都会打版本tag，依然可以通过tag获取该版本的代码