GitFlow实践经验

阅读更多

不了解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流程过渡。