简介
演示前，我们先来看一下这一分支管理模式的3个基本规则
- 规则一，开始工作前，从主干创建特性分支。
- 规则二，通过合并特性分支，形成发布分支。
- 规则三，发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。
由这些规则也可以看出AoneFlow管理模式只有3个角色分支：主干分支、特性分支、发布分支
准备阶段
开始准备，这里创建了一个service与pom文件分别代表服务实现文件与基本配置文件，且生成了Git仓库
服务开发阶段
在这一阶段，我们会进行一些业务开发，服务开发，依据前面的规则，这边我们假设同时有两个服务基于主干进行开发，因此就需要于主干分出两个feature分支
此时两个分支分别进行开发操作，开发完成后分别提交各自开发完成结果
发布阶段
由上文规则我们可以看出，AoneFlow的发布阶段，其实还是从主干分出一个release分支，用这个分支对服务进行合并，然后在合并完成后的该分支上进行测试，测试完成后再将release分支与主分支合并，发布上线主分支版本
在这个阶段是最容易出现冲突的，这是由于两个服务开发的时候都有可能修改到原主干的文件代码，此时手动解决冲突即可
当冲突解决完成，可以在该release分支上继续进行bug解决，测试等动作，但是不应进行服务添加操作，当release达到发布标准时，将release合并回主干分支
发布收尾阶段
该阶段前面的主干已经完成发布，可给对应的服务分支最后版本与发布分支最后版本打上tag，以便后续使用，然后删除对应服务分支与发布分支，这就是一个完整的版本发布了
修复阶段
当一个版本发布上线后发现了一些bug，需要对bug进行修复，也只需要在该发布版本上创建一个新的修复分支，修复完成后等待发布分支合并即可
优缺点
优点：
- 其实该模式最大的优点显而易见，就是灵活，该模式可以在发布版本时进行服务功能选择，自由搭配，但是在合并时可能会产生较多的冲突，当然，如果团队协调较好，对项目分包划分较好，会有效的避免这一问题
- 当需要发布版本的时候，有一些服务还未完成，可以先不对其进行合并，等后续版本再进行服务合并
- AoneFlow最重要的点，就是保证master分支可用和随时可发布，其他都可以是临时分支。
缺点：
- 由于其太过灵活，其具体用法，定义，需要企业根据自己的项目进行一定的定制
- 该模式适合的大多是SaaS类型这类对外只发布最新版本的系统，因为该模式在处理旧版本bug时，只能采取从旧版本主干上分出分支进行处理的方法。
- 由于服务分支之间，其实都是属于隔离的，所以假设一个服务分支想调用另一个服务分支的方法，只能等待下次发布阶段结束后，再去解决
