BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

软件企业从Subversion迁移到Git ,真的准备好了吗?

| 作者 李新 关注 0 他的粉丝 发布于 2012年9月4日. 估计阅读时间: 7 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

除了人,软件公司最宝贵的就是代码了,这些代码大多储存在Subversion(以下简称”SVN”)这样开源的版本控制系统(VCS)中。代码是容易修改和变更的,因此,代码的备份、历史追踪、协同编辑等任务同样需要版本控制系统完成。从最早本地VCS系统RCS、1990年CVS、2000年SVN,到如今开源世界风头正健的Git,同语言编辑工具一样,SVN、Git都是程序员的必备利器。随着GitHub的流行,很多软件企业开始计划转向Git,但是企业真的准备好了吗?

从SVN到Git,不仅仅是工具的替换,还有基于其上的工具和一些管理流程的变化。笔者建议:软件企业需要评估自己当前的状态和企业文化,认真考虑商业目标,谨慎迁移。我们不妨从以下几点来探讨一下。

陡峭的学习曲线

对于采用SVN进行管理的企业,Git相对复杂,开发工程师的学习曲线并不平缓。

Git的命令分为高层和底层,常用的高层命令约有30多个,与SVN近似。这些操作不能继承SVN的经验,因此工程师需要重新学习branch、merge、reset、rebase、revert、pull、fetch等操作命令,需要重新了解哈希值格式的版本号,并用它来进行检出、比较等。

对于较多使用word、ppt、excel、图片、IDE等工具的人员来说,从类似FTP的SVN转向Git ,学习过程会比较痛苦。

缺少角色授权和文件级访问控制

Git作为开源自由原教旨主义项目,它没有对版本库的浏览和修改做任何的权限限制。Git的创始人Linus Torvalds 也曾说:“不要让权限成为政治的理由,Git没有权限控制。”

由于缺少角色授权,因此在组织结构管理上比较困难。实际操作中,一个Git仓库用来实现一个项目,大型项目可能需要许多Git仓库配合实现。在SVN中不同项目在不同目录中,通过角色授权完成组织结构的规划。

实现商业目标的软件企业显然需要文档或代码的访问授权和控制,目前Git本身是不支持的,需要集成第三方工具实现访问控制。

有限的目录检出功能

SVN是一个中心仓库和众多客户端目录的关系,因此,SVN用户都熟悉工作在某个目录上,在不同的工作计算机上,检出目录就可以编辑。然而,Git是一个中心仓库和众多客户端仓库的关系,你必须工作在整个仓库上,虽然在Git1.7版本后支持了类似目录检出的功能,但仍要先检出整个仓库。软件企业的工程师常同时在多个项目中工作,如果修改一点东西就需要克隆仓库,对故障响应将有影响。

浪费已投入的开发成本

软件开发生命周期管理工具的基础是版本控制系统,各商业软件开发管理平台都是基于自主研发的版本控制系统,在此基础上扩展到项目管理、文档管理、代码评审、发布部署、缺陷管理等。基于SVN的开源或自主研发的管理工具非常成熟多样。迁移到Git,则完全浪费了投入到SVN管理工具的开发成本。

图形化工具及接口不够强

虽然Git的图形工具正在增多,但在Windows下还需要等待这些开源工具增强功能。同时,Git的接口待加强,与众多工具集成待完善,这些都是需要时间来解决。

目前很多人倡导的Git的优点并非不可替代

Git速度快,但是SVN使用用廉价的高性能主机同样可以提升速度;Git无需网路也可以工作,但当前稳固的网络基础环境和多样的接入方式,让SVN并不担心网络问题。另外Git方便地处理分支的特性,如果通过控制开发节奏,增加评审,减少分支数量,就可以让分支合并更简单快键,开发会更有效率,SVN也可以更好地管理分支。 SVN的1.7版本以不兼容旧版客户端的代价新增和改进了很多功能,开始向Git靠拢,这也使SVN具备Git的特性。

鉴于以上分享的几个基本点,建议企业谨慎迁移。

笔者对某些场景的命令进行了比较,下表是在Git-1.7 和SVN-1.6上测试的,目的是为了说明SVN的操作经验在Git上不能直接套用,当然Git也有许多独特的优秀功能。

场景 SVN Git
操作动作追踪 所有的操作均作为一次提交,并分配版本号,可追踪 可以撤销某次提交、合并的动作,好像没有发生一样
引用公共库 用链接目录实现
$svn propset svn:externals < module name> < repository_url>
Git 先克隆仓库,再用子模块方式实现
$git clone < repository_url> < directory>
$git submodule add < repository_url>
在本地检出目录 用检出功能实现
$ svn co < repository_url> < directory>
需要先克隆仓库,激活目录检出功能, 通过配置需要保留的目录实现
$git clone < repository_url> < directory>
$cd < directory>
$git config core.sparsecheckout true
$echo < directory> >> .git/info/sparse-checkout
$git read-tree -m -u HEAD
新增文件到中心仓库 用提交功能实现
$svn add < file>
$svn commit –m “new file”
提交后,需要推送到中心仓库
$git add < file>
$git commit –m “new file”
$git push origin

作者简介

李新,新浪产品部高级配置管理工程师,有丰富的软件流程方面的经验。


感谢黄玲艳对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

“企业谨慎迁移”,但应“最终迁移” by 刘 松

这篇文章列出的问题是事实存在的,这些问题多数是因为"分布式版本管理工具"这个本质造成的,是需要开发人员开放心态去学习了解的。
“分布式版本管理”是版本管理工具领域的发展方向,github/googlecode、大量开源项目、IDE的涌入,也见证着它的脚步不可抵挡。从个人角度出发,学习这样的东西,才不至于落后。
文章中没有提及太多git的优势,比方在本地查看提交历史。当然很多时候是只可意会不可言传,用了才知道。比方分支,以我个人的体会,相比git,我绝不会下这样的结论:“SVN也可以更好地管理分支”。
关于角色授权和目录授权,gitolite做的还不错。

网络连接还真的是个问题 by Geng Jet

"Git无需网路也可以工作,但当前稳固的网络基础环境和多样的接入方式,让SVN并不担心网络问题。" 对于这一点真的不敢苟同,因为有不少小公司为了安全考虑没有把代码放到外网可以访问到的服务器上或外网可以访问的vpn。另外开发人员也不一定随时都能联入外网。所以这一点觉得显得尤为重要!

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT