Git基础之git与SVN版本控制优缺点区别分析

目录
  • Git和SVN的区别
    • (1)SVN(集中式版本管理系统)
    • (2)Git(分布式版本管理系统)
  • 2、SVN和Git的优缺点
    • (1)SVN优缺点
    • (2)Git优缺点
  • 3、总结一下

Git和SVN的区别

(1)SVN(集中式版本管理系统)

集中式的版本控制系统都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。

Subversion属于集中式版本控制系统。

  • 好处:

每个人都可以一定程度上看到项目中的其他人正在做些什么。

而管理员也可以轻松掌控每个开发者的权限。

  • 缺点:

中央服务器的单点故障。若是宕机一小时,那么在这一小时内,谁都无法提交更新、还原、对比等,也就无法协同工作。

如果中央服务器的磁盘发生故障,并且没做过备份或者备份得不够及时的话,还会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录,被客户端提取出来的某些快照数据除外,但这样的话依然是个问题,你不能保证所有的数据都已经有人提取出来。

Subversion原理上只关心文件内容的具体差异。每次记录有哪些文件作了更新,以及都更新了哪些行的什么内容。

有很多人认为,集中式的版本控制系统在速度上和性能上是不足的。后来基于集中式的版本控制系统的不足,开发了分布式的版本控制系统。

  • Subversion的特点概括

每个版本库有唯一的URL(官方地址),每个用户都从这个地址获取代码和数据;

获取代码的更新,也只能连接到这个唯一的版本库,同步以取得最新数据;

提交必须有网络连接(非本地版本库);

提交需要授权,如果没有写权限,提交会失败;

提交并非每次都能够成功。如果有其他人先于你提交,会提示“改动基于过时的版本,先更新再提交”… 诸如此类;

冲突解决是一个提交速度的竞赛:手快者,先提交,平安无事;手慢者,后提交,可能遇到麻烦的冲突解决。

(2)Git(分布式版本管理系统)

如下图所示:

以Git为例:

  • Git是一个分布式的版本控制系统,和集中式的控制系统很大的一个差异是,分布式的版本控制系统的服务端和客户端都有完整的一套版本库。那脱离服务端,客户端照样可以管理版本的。并且查看历史以及版本比较等相关操作,都不需要去访问服务器,也就是说分布式的控制系统比集中式的控制系统更能提高版本管理的效率。
  • Git记录版本历史只关心文件数据的整体是否发生变化,Git 不保存文件内容前后变化的差异数据。
    所以Git每次存的都是项目的完整快照,需要的硬盘空间会相对大一点。
    (Git团队对代码做了极致的压缩,最终需要的实际空间比SVN多不了太多,可是Git的回滚速度极快)。
  • 实际上,Git 更像是把变化的文件作快照后,记录在一个微型的文件系统中。每次提交更新时,它会纵览一遍所有文件的指纹信息,并对文件作一快照,然后保存一个指向这次快照的索引。为提高性能,若文件没有变化,Git 不会再次保存,而只对上次保存的快照作一个连接。
  • 在分布式版本控制系统中,客户端并不只提取最新版本的文件快照,而是把原始的代码仓库完整地镜像下来。这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。这类系统都可以指定和若干不同的远端代码仓库进行交互。因此,你就可以在同一个项目中,分别和不同工作小组的人相互协作,你可以根据需要设定不同的协作流程。
  • 另外,因为Git在本地磁盘上就保存着所有有关当前项目的历史更新,并且Git中的绝大多数操作都只需要访问本地文件和资源,不用连网,所以处理起来速度飞快。用SVN的话,没有网络或者断开VPN你就无法做任何事情。但用Git的话,就算你在飞机或者火车上,都可以非常愉快地频繁提交更新,等到了有网络的时候再上传到远程的镜像仓库。

2、SVN和Git的优缺点

(1)SVN优缺点

1)优点:

  • 管理方便,逻辑明确,符合一般人思维习惯。
  • 易于管理,集中式服务器更能保证安全性。
  • 代码一致性非常高。
  • 适合开发人数不多的项目开发。

2)缺点:

  • 服务器压力太大,数据库容量暴增。
  • 必须具有网络环境,单机无法实现版本控制。也就是如果不能连接到服务器上,基本上不可以工作,就不能进行提交,还原,对比等等操作。
  • 注意避免中央集中服务器单点故障。
  • 客户机之间无法直接进行联系。
  • 不适合开源开发(开发人数非常非常多)。但是一般集中式管理的有非常明确的权限管理机制(例如分支访问限制),可以实现分层管理,从而很好的解决开发人数众多的问题。

(2)Git优缺点

1)优点:

  • 适合分布式开发,强调个体。
  • 公共服务器压力和数据量都不会太大。
  • 速度快、灵活。
  • 任意两个开发者之间可以很容易的解决冲突。
  • 可以离线工作。

2)缺点:

  • 学习周期相对而言比较长。
  • 不符合常规思维。
  • 代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

3、总结一下

  • 当研发成本比较低,协作开发人数不多,开发人员对于版本管理的水平参差不齐的时候,或者对于代码的安全性要求更高一点的时候,适合用SVN。
  • 而对于很多人参与开发,代码量比较大,或者高频次协作,跨公司,跨地域合作的情况下,更适合用Git。

参考:https://www.jb51.net/article/245619.htm

以上就是Git基础之git与SVN优缺点及区别分析的详细内容,更多关于git与SVN区别分析的资料请关注我们其它相关文章!

(0)

相关推荐

  • SVN与Git版本控制的优缺点差异全面分析

    目录 一.集中式vs分布式 1.Subversion属于集中式的版本控制系统 Subversion的特点概括起来主要由以下几条: 2.Git属于分布式的版本控制系统 Git具有以下特点: 二.版本库与工作区 1.SVN的版本库和工作区是分离的 2 .Git 的版本库和工作区如影随形 三.全局版本号和全球版本号 1. SVN与Git版本号比较 四.部分检出 1. SVN的部分检出 2. Git的检出 五.更新和提交 1.更新操作 2.SVN中的commit命令 3.Git中的暂存区域(stage)

  • git基础之各版本控制系统介绍

    目录 1.什么是版本控制系统 2.我们为什么要用版本控制 3.版本管理系统的演变 (1)本地版本控制系统 (2)集中化版本控制系统 (3)分布式版本控制系统 1.什么是版本控制系统 版本控制是一种记录一个或若干个文件内容变化,以便将来查阅特定版本修订情况的系统.版本控制系统不仅可以应用于软件源代码的文本文件,而且可以对任何类型的文件进行版本控制. 有了它你就可以将某个文件回溯到之前的状态,甚至将整个项目都回退到过去某个时间点的状态,你可以比较不同版本文件的变化细节,查出最后是谁修改了哪个地方.也

  • 使用版本控制原因及Git与Subversion介绍

    目录 前言 什么是版本控制? 那为什么还要力挺版本控制呢? Subversion 版本控制选择 分布式版本控制系统 Mercurial git 总结 前言 不知道什么是版本库的,扇自己两个大嘴巴:知道但不用的,扇自己四个大嘴巴.快扇去.你真扇了?那你是个大傻瓜.扇什么扇,有扇自己的功夫,还不赶紧去用版本库. 上面那句话是我根据<版本控制之道:使用Git>上一句读者感言发展而来的.版本控制真的那么重要,真的那么好吗? 什么是版本控制? [此段写给需要扇自己两个大嘴巴的人,以及部分需要扇四个大嘴巴

  • Git在项目协作开发中所解决问题

    目录 1.Git的历史 Tips: 2.Git的特点 3.Git在项目协作开发中所解决的问题 1.Git的历史 Git是目前世界上最先进的分布式版本控制系统,开源.免费. Git 是 Linus (林纳斯)为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件. Tips: Linus在1991年创建Linux,现在已经成为最大的服务器系统软件了. Linux的壮大是靠全世界热心的志愿者: 在2002年以前,世界各地的志愿者把源代码文件发给Linus,然后由Linus本人通过手工方

  • Git基础之git与SVN版本控制优缺点区别分析

    目录 Git和SVN的区别 (1)SVN(集中式版本管理系统) (2)Git(分布式版本管理系统) 2.SVN和Git的优缺点 (1)SVN优缺点 (2)Git优缺点 3.总结一下 Git和SVN的区别 (1)SVN(集中式版本管理系统) 集中式的版本控制系统都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新. Subversion属于集中式版本控制系统. 好处: 每个人都可以一定程度上看到项目中的其他人正在做些什么.

  • Git基础之git在项目中的协作模式

    目录 1.分布式工作流程 2.集中式工作流 3.分支工作流 4.GitFlow 工作流(最流行) 5.Forking 工作流(偶尔使用) 6.总结 1.分布式工作流程 与传统的集中式版本控制系统(CVCS)相反,Git 的分布式特性,使开发者间的协作变得更加灵活多样. 在集中式版本控制系统中,每个开发者就像是连接在集线器上的节点,彼此的工作方式大体相像. 而在 Git 中,每个开发者同时扮演着节点和集线器的角色.也就是说, 每个开发者既可以将自己的代码贡献到其他的仓库中,同时也能维护自己的公开仓

  • Git基础学习之分支操作的示例详解

    目录 1.新建一个分支并且使分支指向指定的提交对象 2.思考 3.项目分叉历史的形成 4.分支的总结 1.新建一个分支并且使分支指向指定的提交对象 使用命令:git branch branchname commitHash. 我们现在本地库中只有一个 master 分支,并且在 master 分支有三个提交历史. 需求:创建一个 testing 分支,并且testing 分支指向 master 分支第二个版本. # 1.查看提交历史记录 L@DESKTOP-T2AI2SU MINGW64 /j/

  • Git基础学习之文件删除操作命令详解

    目录 1.删除文件说明 2.删除文件操作 (1)仅删除暂存区的文件 (2)完全删除文件 3.本文用到的命令总结 1.删除文件说明 在Git工作目录中要删除某个文件,首先要清楚该文件所处的状态. 若要是该文件未被Git管理,在工作区直接进行删除即可.(不演示) 但是,若该文件已经经过多次git add与git commit操作后,就必须要从已跟踪文件清单中删除(确切地说,是在暂存区中删除),然后提交. 可以用git rm命令完成此项工作,并连带从工作目录中删除指定的文件,这样文件之后就不会出现在未

  • Git基础学习之tag标签操作详解

    目录 共享标签 推送本地的指定标签 推送本地所有为推送的标签 查看结果 删除标签 删除本地标签 删除远程标签 修改标签指定提交的代码 标签在.git目录中的位置 本文中所使用到的命令 共享标签 默认情况下,git push 命令并不会传送标签到远程仓库服务器上. 在创建完标签后,你必须显式地(手动)推送标签到远程服务器上. 需要将标签推送到远程版本库作为一个发行版本,可以通过以下两种方式: 推送本地的指定标签 这个过程就像共享远程分支一样,你可以执行命令: git push origin <ta

  • Git基础学习之分支基本操作详解

    目录 1.创建分支 (1)创建分支 (2)图示理解 2.查看分支列表 3.分支切换 4.查看所有分支的最后一个提交 5.删除分支 1.创建分支 (1)创建分支 Git 是怎么创建新分支的呢? 很简单,就是要创建一个可以移动的新的指针. 比如,创建一个testing分支, 你需要使用命令:git branch testing. 示例: # 1.查看本地版本库历史提交 L@DESKTOP-T2AI2SU MINGW64 /j/git-repository/learngit (master) $ gi

  • Git科普文,Git基本原理及各种骚操作(推荐)

    Git简单介绍 Git是一个分布式版本控制软件,最初由Linus Torvalds创作,于2005年以GPL发布.最初目的是为更好地管理Linux内核开发而设计. Git工作流程以及各个区域 Workspace:工作区 Staging/Index:暂存区 Local Repository:本地仓库(可修改) /refs/remotes:远程仓库的引用(不可修改) Remote:远程仓库 Git文件状态变化 Git各种命令 Git简单命令 # 在当前目录新建一个git仓库 git init # 打

  • git revert和git reset的区别详解

    git revert和git reset的区别 git revert 是生成一个新的提交来撤销某次提交,此次提交之前的commit都会被保留 git reset 是回到某次提交,提交及之前的commit都会被保留,但是此次之后的修改都会被退回到暂存区 具体一个例子,假设有三个commit, git st: commit3: add test3.c commit2: add test2.c commit1: add test1.c 当执行git revert HEAD~1时, commit2被撤销

  • Git fetch和pull的详解及区别

    git fetch和pull的区别 Git中从远程的分支获取最新的版本到本地有这样2个命令: 1. git fetch:相当于是从远程获取最新版本到本地,不会自动merge Git fetch origin master git log -p master..origin/master git merge origin/master 以上命令的含义: 首先从远程的origin的master主分支下载最新的版本到origin/master分支上:然后比较本地的master分支和origin/mas

随机推荐