flow & staging

[aligo]

git flow很好。规范了develop和master两条flow的管理方式，简单清晰明确。

但是实际上我在使用时还是会至少在develop和master时间加入两个staging（小项目如此，如果多人进行的大项目可能还会加入更多？）
就像这样:
develop > staging1 > staging2 > master

对于web开发来说：
staging1 用于发布到本地。一般不会用上，会直接跳过。但是有些时候进行环境参数或者数据库的变动，就会先把代码发布到本机（挺奇怪的吧？），这样如果发现问题可以直接在本机上方便以快照的方式恢复。

staging2 这个就是传统意义上用于staging的flow了。没问题再进入master。

这样结合git flow的流程来看：
feature 还是一样。
release 需要决定发布到哪个staging，只能从左向右进行。（是否需要可以从非develop的flow进行一次release，还是只能从develop开始？）
hotfix和support 这是最有意思的部分了。例如对staging2进行一次hotfix，就同时向staging2以左的flow都应用该hotfix。

我自己保持这样的方式运作了一段时间，没有不良反应。

不过git进行这些事情还是有点麻烦，估计还是得整理成git-flow那样的脚本比较科学。

就是这样，欢迎各种建议意见。

[linjunpop]

觉得直接 dev -> master 就可以了，太多反而有点乱。Production 直接用 master 上的 tag 控制就好。:D

[aligo]

@linjunpop 我觉得这样也还是有点交叉的问题
例如staging和production运作着不同的tag啊，然后需要修复production的问题，又不想发布在staging多出来的那部分东西囧