`
神奇的九戒
  • 浏览: 987 次
  • 性别: Icon_minigender_1
  • 来自: 上海
最近访客 更多访客>>
社区版块
存档分类
最新评论

Gti 和其他版本控制的比较

    博客分类:
  • Git
 
阅读更多
目前网站代码网站的开发用的版本管理器是SVN ,其开源,操作简单,能和多数IDE集成,深受大多数开发者的喜爱。但是SVN的缺点也是十分的明显,如:需要时时连接到服务器和进行版本对比还原,一旦版本服务器崩溃,整个代码都是基本都会丢失了;多分支同步开发困难。
Git 版本服务器以其开源操作简单也慢慢让大家认可。下面对比下svn和git两个服务器的区别
1. 集中式 vs 分布式
1.1 SVN属于集中式的版本控制系统
集中式的版本控制系统都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。多年以来,这已成为版本控制系统的标准做法。
这种做法带来了许多好处,特别是相较于老式的本地VCS(版本服务器) 来说。现在,每个人都可以一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限。
事分两面,有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。若是宕机一小时,那么在这一小时内,谁都无法提交更新、还原、对比等,也就无法协同工作。如果中央服务器的磁盘发生故障,并且没做过备份或者备份得不够及时的话,还会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录,被客户端提取出来的某些快照数据除外,但这样的话依然是个问题,你不能保证所有的数据都已经有人提取出来。
Subversion的特点概括起来主要由以下几条:
1)、 每个版本库有唯一的URL(官方地址),每个用户都从这个地址获取代
码和数据;
2)、获取代码的更新,也只能连接到这个唯一的版本库,同步以取得最新数据;
3)、提交必须有网络连接(非本地版本库);
4)、提交需要授权,如果没有写权限,提交会失败;
5)、 提交并非每次都能够成功。如果有其他人先于你提交,会提示“改动基于
过时的版本,先更新再提交”… 诸如此类;
6)冲突解决是一个提交速度的竞赛:手快者,先提交,平安无事;手慢者,后提交,可能遇到麻烦的冲突解决。
1.2 Git属于分布式的版本控制系统
自2005年诞生于以来,Git 日臻成熟完善,在高度易用的同时,仍然保留着初期设定的目标。它的速度飞快,极其适合管理大项目,它还有着令人难以置信的非线性分支管理系统,可以应付各种复杂的项目开发需求。
与SVN不同,Git记录版本历史只关心文件数据的整体是否发生变化。Git 并不保存文件内容前后变化的差异数据。实际上,Git 更像是把变化的文件作快照后,记录在一个微型的文件系统中。每次提交更新时,它会纵览一遍所有文件的指纹信息并对文件作一快照,然后保存一个指向这次快照的索引。为提高性能,若文件没有变化,Git 不会再次保存,而只对上次保存的快照作一连接。
在分布式版本控制系统中,客户端并不只提取最新版本的文件快照,而是把原始的代码仓库完整地镜像下来。这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此,你就可以在同一个项目中,分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程。
另外,因为Git在本地磁盘上就保存着所有有关当前项目的历史更新,并且Git中的绝大多数操作都只需要访问本地文件和资源,不用连网,所以处理起来速度飞快。用SVN的话,没有网络或者断开VPN你就无法做任何事情。但用Git的话,就算你在飞机或者火车上,都可以非常愉快地频繁提交更新,等到了有网络的时候再上传到远程的镜像仓库。换作其他版本控制系统,这么做几乎不可能,抑或是非常麻烦。
简略的说,Git具有以下特点:
1)、Git中每个克隆(clone)的版本库都是平等的。你可以从任何一个版本库的克隆来创建属于你自己的版本库,同时你的版本库也可以作为源提供给他人,只要你愿意。
2)、 Git的每一次提取操作,实际上都是一次对代码仓库的完整备份。
3)、 提交完全在本地完成,无须别人给你授权,你的版本库你作主,并且提交总是会成功。 甚至基于旧版本的改动也可以成功提交,提交会基于旧的版本创建一个新的分支。
4)、Git的提交不会被打断,直到你的工作完全满意了,PUSH给他人或者他人PULL你的版本库,合并会发生在PULL和PUSH过程中,不能自动解决的冲突会提示您手工完成。
5)、 冲突解决不再像是SVN一样的提交竞赛,而是在需要的时候才进行合并和冲突解决。
6)、 Git 也可以模拟集中式的工作模式Git版本库统一放在服务器中 可以为 Git 版本库进行授权:谁能创建版本库,谁能向版本库PUSH,谁能够读取(克隆)版本库 团队的成员先将服务器的版本库克隆到本地;并经常的从服务器的版本库拉(PULL)最新的更新; 团队的成员将自己的改动推(PUSH)到服务器的版本库中,当其他人和版本库同步(PULL)时,会自动获取改变
7) Git 的集中式工作模式非常灵活,你完全可以在脱离Git服务器所在网络的情况下,如移动办公/出差时,照常使用代码库 你只需要在能够接入Git服务器所在网络时,PULL和PUSH即可完成和服务器同步以及提交 Git提供 rebase 命令,可以让你的改动看起来是基于最新的代码实现的改动
8) Git 有更多的工作模式可以选择,远非 Subversion可比
2.下面简易介绍一下SVN和GIT的优缺点
2.1 SVN优缺点
优点:
1、 管理方便,逻辑明确,符合一般人思维习惯。
2、 易于管理,集中式服务器更能保证安全性。
3、 代码一致性非常高。
4、 适合开发人数不多的项目开发。
缺点:
1、 服务器压力太大,数据库容量暴增。
2、 如果不能连接到服务器上,基本上不可以工作,看上面第二步,如果服务器不能连接上,就不能提交,还原,对比等等。
3、 不适合开源开发(开发人数非常非常多,但是Google app engine就是用svn的)。但是一般集中式管理的有非常明确的权限管理机制(例如分支访问限制),可以实现分层管理,从而很好的解决开发人数众多的问题。
2.2  Git优缺点
优点:
1、适合分布式开发,强调个体。
2、公共服务器压力和数据量都不会太大。
3、速度快、灵活。
4、任意两个开发者之间可以很容易的解决冲突。
5、离线工作。
缺点:
1、学习周期相对而言比较长。
2、不符合常规思维。
3、代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
3. 其他的版本服务器介绍
1 . ClearCase  收费的集中式版本控制系统,安装包特别大,运行慢。
2 . VSS微软自己也有一个集中式版本控制系统叫VSS,集成在Visual Studio中。性能差, 只支持widows平台下。
3.BitKeeper  布式版本管理器,但是是收费。
4.Mercurial分布式开源项目。但是是用python 运行速度没有git快。

4.总结
从开源,协同,开发自由行角度看git 是个很好的选择。从控制权限细节角度看svn是一个很好的选择。现在网站用的是svn,使用git就增加了学习成本。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics