不了解GitFlow的先看：https://www.cnblogs.com/myqianlan/p/4195994.html
GitFlow中各分支的基本作用：
master--现网代码备份，永远与现网一致
develop--用于收集汇总一个迭代中需要发布的feature
feature--用于开发独立的功能
release--用于提测和发布迭代中需要上线的功能
hotfix--修复现网bug
在实践中，这种标准做法目前存在一些问题，因为：
1.在迭代界限清晰的情况下，develop分支收集迭代中要发布的feature和hotfix，一并发布。而C端常因为各种原因无法按期上线（如遇到技术障碍；临时需求/需求遗漏；外部原因变化），发布时间很容易出现偏差。
2.hotfix通常比较紧急，无法等待下次固定时间点发布
3.功能上线时间比较急，功能完成后就需要尽快发布
所以，目前最适合的是采取类似敏捷的方式，尽量
避免已封版功能等待未封版功能，所以无法有效利用develop收集feature，
实际中有3种变通的做法：
1. 基于master手动创建feature，开发完后基于feature手动创建release提测并发布，再finish release，这种做法类似hotfix
2. start feature（默认基于develop），开发完后基于feature手动创建release提测并发布，再finish release
3. 不使用feature（避免finish feature后合回develop），开发时直接start release，在release上开发，提测改bug，最后finish所有要同时上线的release，再用master/develop上线
建议采用第三种做法，流程简单，不会相互干扰。
这3种变通做法都避免了feature合回develop的步骤，
以后在技术水平提升、管理规划加强、风险控制能力提高的条件下，可以逐步
固化发布周期，
向标准GitFlow流程过渡。