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那样的脚本比较科学。
就是这样,欢迎各种建议意见。
但是实际上我在使用时还是会至少在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那样的脚本比较科学。
就是这样,欢迎各种建议意见。


