这是一个创建于 4602 天前的主题，其中的信息可能已经有所发展或是发生改变。
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那样的脚本比较科学。
就是这样，欢迎各种建议意见。
 |
1
linjunpop 2012-06-07 19:37:22 +08:00
觉得直接 dev -> master 就可以了，太多反而有点乱。Production 直接用 master 上的 tag 控制就好。:D
|
Select Language