银行项目从 SVN 迁移到 Git

栏目: 编程工具 · 发布时间: 5年前

内容简介:本人目前做某银行互联网支付平台项目。 自入职加入这个项目开始就一直使用svn进行代码版本控制,开发,测试,生产共用一个仓库,仅一个分支。 一开始有需求就在base版本进行改动,修改完成直接提交,或者在测试环境替换class文件。 修改生产问题,也是相当的小心,担心出现问题,由于新旧代码可能不一样,总是被逼反编译后使用compare进行比较后才能确认有无问题。当然svn也有版本管理的概念,我也曾尝试;trunk、tags、branches分文件夹管理。 如下图:同时每个项目我又参考了gitflow初始化为m

一、迁移流程

本人目前做某银行互联网支付平台项目。 自入职加入这个项目开始就一直使用svn进行代码版本控制,开发,测试,生产共用一个仓库,仅一个分支。 一开始有需求就在base版本进行改动,修改完成直接提交,或者在测试环境替换class文件。 修改生产问题,也是相当的小心,担心出现问题,由于新旧代码可能不一样,总是被逼反编译后使用compare进行比较后才能确认有无问题。

当然svn也有版本管理的概念,我也曾尝试;trunk、tags、branches分文件夹管理。 如下图: 银行项目从 SVN 迁移到 Git

其原理是copy一份(虽然服务端也是增量改动),但是客户端一个项目10M, 10个项目10个版本则10 10 10,这是我不能忍的。而且使用繁琐,一个工程会有好多的workspaces。

一个偶然的机会,公司总部的某个项目在gitlab下,正好需要落地到项目地,于是我向公司申请,把我们项目组所有项目迁移到了gitlab 某个group中, 如图:

银行项目从 SVN 迁移到 Git

同时每个项目我又参考了gitflow初始化为master分支,又切出了develop分支,testing分支。贴参考的图:

银行项目从 SVN 迁移到 Git

对于各个分支 我的理解为:

  • 【master】:与生产版本对应并基于【master】打tag.

  • 【hotfix/fix_telno】:热修复版本,基于【master】切出来的, 解决生产小问题,紧急上线后。并合并到【master,develop】.

  • 【develop】 :开发分支,永远是不稳定的版本,所有开发周期完成待上线测试的特性分支都在该版本中。 【feature/netsunion】:基于【develop】分支切出来的特性分支。

  • 【release/1.2.1】:测试完成后的beta版本,用作回归测试,待发布上线。

  • 【testing】:用于特性分支开发中的测试。所有特性分支需测试都merge到该分支。

  • 比如一个新需求的开发是对接网联接口,我会按照如下进行操作:

  1. 基于【develop】checkout -b feature/netsunion,并推送到远端;

  2. 基于【feature/netsunion】这个分支进行开发,如果需要在测试机器测试的话就合并到【testing】分支,进行打版测试,当完成开发并确定为下次上线内容后将合并到【develop】,并删除【feature/netsunion】分支。否则一直保持【feature/netsunion】存在,直到确定了上线日期。

  3. 等所有feature完成开发并合并到【develop】分支后,基于【develop】切出【release/1.2.1】版本,基于【release/1.2.1 】进行回归测试。

  4. 回归完成就进行上线工作准备,完成上线后合并到【master】并打标签【V1.2.1】;删除【release/1.2.1】;

  5. 结束

其实我是不主张用testing分支的,我理想中的是特性分支开发完成后就在测试环境进行验证,但事与愿违,无奈行方无法提供更多台测试机,再者多个特性分支需要整合一起统一测试等等原因,无奈新建该分支。 如果过分依赖该分支很容易出现生产问题测试环境不复现的情况,比如出现冲突解决不一致的情况等。所以每个版本必须通过release进行验证后在进行上线操作。

通过切换到git解决了我们开发的痛点:

  1. 生产版本的源代码管理。

    由原始的本地备份改为分支管理,避免过分依赖于某个备份人,当他机器挂掉或者不在场再或者备份的与生产不一致的尴尬;

  2. 解决多个需求的并行开发,使代码没有那么多判断逻辑。

    以前properties中各种开关,当上线这个功能就打开等等,通过feature分支需要哪个功能合并就好了,代码简洁了许多;

  3. 使IDE的 一个workspace支持多个分支的开发。

    checkout 命令后,IDE 刷新即可。

  4. 通过部署 工具 或自写脚本实现自动化部署,以前测试环境中都是本地编译好class后直接放到测试环境中,多个服务器需要重复上传,费事费力。

    现在只需提交到对应的分支或者合并到testing分支,通过工具选择分支进行打版部署即可。

二、常用工具:

我们是通过命令行 + 图形工具结合使用:

  • 一般新建分支什么的使用【Git Bash】像合并解决冲突;

  • 查看历史记录等使用【Git Extensions】 + 【Beyond Compare 4 】 ;

对于git命令 相信各位大神比我更熟悉。 基础语法命令链接

Q&A

Q:svn和git有这么大区别?git的好处是分布式,可以先本地提交;

A:但是svn 对于分支管理确实不方便。多个版本并行开发,本地会存在多个副本。还是那句话;没有最好的工具,只有合适的工具。好处就是本地可以有个版本库;

Q:clearcase 我还以为CC只在主机平台用呢,还在用VSS做文档服务器?

A:经典 + 元老级

Q:怎么找到丢失的 commit?

A:丢掉的commit ,是还没有提交本地?,文件被还原了吗? 

Q1:提交到本地 没有远端push。

A2:那就没有丢掉嘛 记录都还在。

Q:你们功能特性分支是怎么切的呢?

A:上线后合并到主分支,开发新功能切个分支出来,恩恩,明白了。你们是基于master切出特性分支。我是严格参照gitflow,基于的是dev分支。那样的话如果有ABC三个特性分支,而且全部需要进行测试,下一个版本仅仅上线AB功能。

补充

  • 个人感觉,git和svn适用于不同的场景,git可能更适用于运营项目;

  • release统一是master,发布测试版本合并到dev,测试通过合并到master,其他开发分支从master拉。实际接触的几个项目,用git基本是因为放弃了配置管理,感觉从配管的角度上看,svn有利于保持基线完整。

  • CC是个不错的管理工具。

  • 敏捷的目标不是图快,也不是裁剪,对设计和编码要求很高,对配管要求更高,国内就是这样,老板大腿一拍搞敏捷就开完,没真正领略敏捷内涵,敏捷还是老外玩得溜,敏捷说白了是牺牲资源,加快速度,适应市场。

  • git flow 中 release是基于的dev,如下:

    银行项目从 SVN 迁移到 Git

以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

游戏开发的数学和物理

游戏开发的数学和物理

[ 日] 加藤洁 / 徐 谦 / 人民邮电出版社 / 59.00元

本书严格选取了游戏开发中最常用的数学和物理学知识,通过游戏开发实例,配上丰富的插图,以从易到难的顺序进行讲解。第1章到第5章分别讲解了物体的运动、卷动、碰撞检测、光线的制作、画面切换的细分处理。这五章将2D游戏必需的知识一网打尽,同时还严格挑选了少量3D游戏编程的基础内容以供参考。第6章系统梳理了游戏开发的数学和物理学理论,帮助读者更好地理解前五章的内容。 本书适合网络和手机游戏开发者阅读。一起来看看 《游戏开发的数学和物理》 这本书的介绍吧!

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具