IT干货网

svn代码版本管理

developer 2022年03月12日 编程设计 173 0

1.0开发,做dev1.0的branch
此时的目录结构
svn://proj/
             +trunk/ (不负担开发任务)
             +branches/
                           +dev_1.0 (copy from trunk)
             +tags/ 
1.0开发完成,merge dev1.0到trunk
此时的目录结构
svn://proj/
             +trunk/ (merge from branch dev_1.0) ===>测试,打tag或者修改合并后的bug,担负bug代码修改
             +branches/
                           +dev_1.0 (开发任务结束,freeze)
             +tags/ 
1) 合并后,测试如果有bug,可以直接在trunk上修改bug,直到修正后打tag进行发布
2)合并后,测试无问题直接打tag发布
发布后发现存在bug:需要修改,基于1.0的tag做branch_buffix_1.0
此时的目录结构
svn://proj/
             +trunk/ 
             +branches/
                           +dev_1.0 (开发任务结束,freeze)
                           +dev_2.0 (进行2.0开发)
               +branch_buffix_1.0
             +tags/
                     +tag_release_1.0 (copy from trunk) 
    1)如果2.0开发开始,但并没合并入主干:branch_buffix_1.0中修正bug后合并到主干,通过主干打tag发布
    2)如果2.0开发结束,而且合并入主干:branch_buffix_1.0中修正bug后依然合并到主干,但通过分支branch_buffix_1.0打tag发布
依次类推!!

总结:
1)tag上不做任务代码修改
2)新需求开发,从主干(最新稳定的)做分支在分支上开发
3)新需求分支开发完成或者分支bug修正后,都必须合并到主干
4)主干可在合并后发现问题(并没打tag)做部分修改

这是方法之一,比较适用于那些经常改动,bug较多的网站开发。


评论关闭
IT干货网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

[转]spring mvc注解方式实现向导式跳转页面