1.Feature分支：
Feature分支开发新需求，或大的改动。从最新的Develop/master建立的分支。
特殊情况处理：
1）问题一：新建时，其他Feature 已经合并到Develop但是还没有发布（即有不稳定代码），则从Master手动拉取分支代码。上图Feature6的情况。
1）问题二：Feature完成时，其他Feature已经合并到Develop但是还没有发布（即有不稳定代码），则先在Feature上发布，其他Feature发布完成再合并到Develop,走git_flow流程。上述Feature002的情况。
2.Release维护分支
Release维护分支，从最新的Develop/master建立的分支，作为阶段性维护，针对多临时发版建来做阶段计划（阶段，可解释为正式发布客户端版本到客户为结束，可以是一家客户，也可以是多家客户相同时间点的代码）维护， 打一个包，则在该分支打一个tag，按阶段计划，代码同步到maste分支和develop分支上，最后一个tag就是发版的tag，
特殊情况处理：
1）往master同步代码时，检查新需求如果已发布（此时master已有新需求代码），则把代码从master（包含新需求）合过来（因为这里有合并操作，所以尽量控制合并的代码周期不要要长,一周比较好）。进行新需求与最新代码的合并代码测试（上图同步3）。测试完成后（可能已经经过了一段时间），再次按上述检查是否又有新需求发布（master又有新需求代码），此种情况较少，需求较近，可以提前预测，把2个需求一起合并再测试。直到master上已经没有变更时，把测试好的代码合并到master。develop也类似，直到develop上已经没有新需求提交时变更时，合并代码到develop。master可能落后develop，所以develop要检查。避免其他需求合并了但是还没有发布。
维护阶段结束升级该维护分支版本号+1。（方法：完成并删除该分支，从稳定分支上master/develop重新拉取一个新的release维护分支，版本号+1）
3.重要bug或非常紧急bug，修改时单独修改，单独提交，不要跟其他bug修改混在一起，修改外完后，采用类似广播通知的形式通知各个分支维护人同步。master除外的其他的分支均进行同步.
综合优势：
1.长期维护的分支就一条，通用性bug一并修改，减少分之间同步操作，不用来回切换，也不用随时同步其他分支代码。因为维护修改的代码比较少，属于小改动，风险可查，可控.但是周期长，打包多，杂，一个版本一个分支太浪费，也不好管理，如果改动大的可以考虑单独拉一条开发功能分支，此分支只需要定时阶段性向develop和master同步代码，以使新需求合并时开发可以拿到develop上比较新的稳定代码进行合并。
2.新需求完成时选择同步的develop代码是稳定的，develop平常都是维护版本发版后同步的代码，是稳定的代码，不稳定的只有需求与需求之间的代码不稳定的情况。后完成的需求在前面需求未发布的情况下可以选择先发布再延时合并测试。所以新需求也是比较稳定的，
5.maste就是在deveop不稳定的时候，可以用来拉新分支用的。
