Subversion svn 分支策略 by 深圳-CM-simple

laofo · 发布于 2016年3月27日 · 50 次阅读
4

深圳-CM-simple(283885079) 5:33:30 PM 有些问题想要请问一下大家,我是刚开始做配置管理的新人,目前公司用的版本管理工具是SVN ,之前了解的SVN仓库一般是分为trunk branch tag目录 ,基本主要开发提交代码都是提到trunk 而现在公司有多项目要并行 所以设计的SVN库上是分为 开发 系统测试ST 验收测试UAT 和生产PRD 四个目录 比如同时两个项目进来 就在开发下新建两个目录p01 p02 然后从tag/生产/产品 目录svn copy出相应要进行开发的产品代码到开发/P01目录下 p02目录 及ST和UAT目录下 若项目1 2是同时上ST的 则开发完后申请上ST,对开发完的项目打TAG到/TAG/DEV/P01目录下 再用svn客户端的merge功能合并P01到ST目录 P02开发完 再merge到ST目录 如果系统测试有bug 就在相应项目开发流修改后重新打标签 合并上系统测试 系统测试完没有问题后 打TAG到/TAG/ST/产品名目录下 然后将系测试的代码从TAG/ST下合并到UAT 验收测试的目录下 如果UAT没有问题 打TAG到/TAG/UAT/产品 目录下 再合并到生产PRD目录下 基本流程是这样 这里想问的是 群里有用SVN 进行多项目管理经验的朋友吗 像上边我说的这个流程 svn copy 或者打TAG 都会产生很多分支 到时候随着项目的增多 估计用svn客户端的查看版本分支图 会一片混乱 再者合并次数会很多 如果哪里没弄好 不同祖先的话 可能合并会有问题 麻烦神有时间的时候帮忙指导一下 非常感谢哈

深圳-CM-simple(283885079) 6:08:52 PM 主要是这样 合并次数会很多 分支也会很多 群里有用svn 管理并行项目的经验的前辈吗 北京-恐龙(270987472) 6:16:49 PM 只能说 你们这个分支实用策略是前人遗留的垃圾 北京-恐龙(270987472) 6:18:33 PM 尽量缩减一个产品代码 从进入测试、 功能测试几本验证完毕 的分支合并次数 基本 深圳-CM-simple(283885079) 6:20:37 PM 就是你们管理并行项目的策略是怎么样的呢 我也觉着这个分支太多 合并次数也太多 很麻烦容易出错 北京-恐龙(270987472) 6:22:30 PM 功能分支(验证) → 合并trunk二次回归验证(研发人员代码开发习惯较差、svn合并功能使用长出错)/发布完再合并trunk(研发人员工具使用和代码开发习惯较好)

共收到 1 条回复
4
laofo · #1 · 2016年3月28日

深圳-CM-simple: 主要是这样 合并次数会很多 分支也会很多 群里有用svn 管理并行项目的经验的前辈吗 北京-恐龙(: 只能说 你们这个分支实用策略是前人遗留的垃圾 北京-恐龙: 尽量缩减一个产品代码 从进入测试、 功能测试几本验证完毕 的分支合并次数 基本 深圳-CM-simple: 就是你们管理并行项目的策略是怎么样的呢 我也觉着这个分支太多 合并次数也太多 很麻烦容易出错 北京-恐龙: 功能分支(验证) → 合并trunk二次回归验证(研发人员代码开发习惯较差、svn合并功能使用长出错)/发布完再合并trunk(研发人员工具使用和代码开发习惯较好) 深圳-CM-simple: 之前公司的trunk branch tag 比较好 但是现在这个公司经常会项目并行 且子产品要能快速独立的出版本 北京-恐龙: 快速独立 和 多次重复合并是两件事 北京-laofo: 你们的产品是不是还要同时维护对多个版本的bug 修复?如果那样,你这个分支策略可比你画的复杂多了。 深圳-CM-simple: 嗯 对 马上要正式开始用这一套东西 我个人是感觉后续会很乱 深圳-CM-simple: 所以问问大家多项目并行是怎么处理的 北京-恐龙: 多项目 和多版本 不是一个概念 北京-恐龙: 项目代码各自维护各自的, 同项目的多个性分支照目前国内的开发尿性,也几本上是各维护各的分支。能合并在一个trunk的很少 上海-鱼小二(: 上UAT和PROD难道需要重新各构建一次? 那测试的话加上集成测试环境要完整回归三次? 上海-鱼小二: 而且你这个图有点问题,p01上了st以后的改动不merge回p02会产生冲突的 深圳-CM-simple: 嗯 冲突在合到ST的时候解决 上海-鱼小二: 你这个工作量好大 我们多项目只在dev,只在集成测试合并一次 上海-鱼小二: 过就直接上生产 上验证再上生产 深圳-CM-simple: 我们这边主要也是在ST合并 因为在ST已经合并过了 上UAT 或者生产的时候 基本合并时都是没有冲突的 直接就合并过去了 北京-菜鸟-求指: 有人在嘛 北京-恐龙: 多根据自己公司产品发展状态来 优化分支使用和合并的层次, 尽量少能保持在1~2次的合并就能完成 所有产品的编译 北京-菜鸟-求指: 哪里可以找到winpe 北京-恐龙: 百度下 找运维 深圳-CM-simple: 比如说只 P01 P02在ST的时候合并一次 ST 有BUG就会开发流改完打标签重新上ST合并 验完没有bug了 打好标签 如果没有UAT PRD 那UAT PRD出BUG了 怎么处理呢 从ST打的标签里分支出来修改吗 深圳-CM-simple: 上UAT 和PRD 都取ST那里代码 编译出的包 ? 深圳-CM-simple: 谢谢大家耐心的解答 北京-恐龙: 从标签上拉 分支出来改 改完合并 深圳-CM-simple: 分支上改完合并回去后 分支还会保留吗 还是直接删了 上海-闲: 。。。。。 深圳-CM-simple: 可能我说的有些不对 因为没什么经验 见谅 北京-恐龙: 你要是打了tag 就没必要保留 或者周期性保留 到第3次上线发布,那么第1次的就没什么重要性了 上海-鱼小二: 如果在测试环境封测了我觉得没必要再编译一次了 可以直接上验证 深圳-CM-simple: 这里想到一个问题 就是UAT 或者PRD发现bug 从ST的标签中拉分支出来改 这个时候P03完成开发 合并到ST了 那拉出来的 分支合回去的话 就是包含了P03的代码的 这样的话 bug修改的代码编译打包 就只能去分支上的了 是吗 深圳-CM-simple: @上海-鱼小二 主要ST完 上UAT 怕UAT 有问题 修改了bug UAT侧的代码会与ST的不一样 上海-鱼小二: 我们上验证有问题直接回集成测试环境 上海-鱼小二: 这里想到一个问题 就是UAT 或者PRD发现bug 从ST的标签中拉分支出来改 这个时候P03完成开发 合并到ST了 那拉出来的 分支合回去的话 就是包含了P03的代码的 这样的话 bug修改的代码编译打包 就只能去分支上的了 是吗 你这个分支不能合回去,不然就p03的东西就被你带上生产了吧。 深圳-simple: 嗯 对 我就是要表达这个意思 所以这么问 北京-恐龙: 再所谓的PRD bug修改时 P03代码能合并,那是领导煞笔

深圳-simple: 没有 是我自己在想怎么弄才OK 想到这个就问了 分支上取代码编译打包 出补丁包 ST那边合了P03的代码 最后还是要合PRD修改bug的代码 要不ST上的代码还是有问题 对吧 上海-鱼小二(370114048) 10:07:12 PM 如果他们的流程那么复杂的话,是没法避免合并的时候修bug的 深圳-simple: 嗯 他们之前用的clearcase 就是这一套流程 现在换SVN了 还是希望用这一套 我个人是感觉这样分支很多 要做很多次合并 感觉特别麻烦 也很容易出错 北京-恐龙: 好像CC 就不麻烦了 深圳-simple: 我没有用过CC 上海-鱼小二: 建议他们简化一下呗 广州-Allen: 我之前用cc,后来推Git了,分支策略是通用的,和工具没直接的关系,看你实际场景需要 深圳-simple: 嗯 好滴 非常感谢打击 非常感谢大家

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册