SVN和Git比较

Dear 丶 2022-07-16 13:23 166阅读 0赞

# 版本控制 #

什么是“版本控制”？我为什么要关心它呢？  
版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。 对我们来说，我们需要对保存着软件源代码的文件作版本控制，但实际上，你可以对任何类型的文件进行版本控制。  
有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。 使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。 但额外增加的工作量却微乎其微。

我们大家都知道，如果编程时一点都没备份，那么出错后，想改正会非常难。

# 三种类型的版本控制系统 #

## 本地版本控制系统 ##

![本地版本控制系统][20161119095404338]  
**图一 本地版本控制系统**

起源：  
许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单，但是特别容易犯错。 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。  
为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。  
其中最流行的一种叫做 RCS，现今许多计算机系统上都还看得到它的踪影。它的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。

## 集中化的版本控制系统 ##

![集中化的版本控制系统][20161119095536060]  
**图二 集中化的版本控制系统**

起源：  
人们接着就碰到问题了，怎么让多台电脑或不同系统的开发者协同工作呢？于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。 这类系统，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。 多年以来，这已成为版本控制系统的标准做法。  
相比以前的好处：  
相较于老式的本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。  
最大的缺点：  
这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。  
本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。

## 分布式版本控制系统 ##

![分布式版本控制系统][20161119095646060]  
**图三 分布式版本控制系统**

起源：  
为了降低服务器爆炸造成的风险，最直接的方法，多备份。  
于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。 在这类系统中，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。  
这么一来，任何一处协同工作用的服务器发生故障，事后都可以用一个最新的备份将服务器的数据恢复回来。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。  
而且，更进一步，很多此类系统不仅仅可以和一个服务器进行通信，还可以和其他的指定的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

# SVN #

## 介绍 ##

SVN是Subversion的简称，是一个开源的版本控制系统,支持大多数常见的操作系统。作为一个开源的版本控制系统，Subversion管理着随时间改变的数据。这些数据放置在一个中央资料档案库(repository)中。这个档案库很像一个普通的文件服务器,不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本，或是浏览文件的变动历史。Subversion是一个通用的系统,可用来管理任何类型的文件,其中包括了程序源码。  
而且，目前绝大多数开源软件都使用SVN作为代码版本管理软件。

## 特点 ##

1.  每个版本库有唯一的URL（官方地址），每个用户都从这个地址获取代码和数据；
2.  获取代码的更新，也只能连接到这个唯一的版本库，同步以取得最新数据；
3.  提交必须有网络连接（非本地版本库）；
4.  提交需要授权，如果没有写权限，提交会失败；
5.  提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”… 诸如此类；
6.  冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决。

# Git #

## 简史 ##

同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。  
Linux 内核开源项目有着为数众广的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。 到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。  
到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linux Torvalds）基于使用 BitKcheper 时的经验教训，开发出自己的版本系统。 他们对新的系统制订了若干目标：  
a) 速度  
b) 简单的设计  
c) 对非线性开发模式的强力支持（允许成千上万个并行开发的分支）  
d) 完全分布式  
e) 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）  
自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。 它的速度飞快，极其适合管理大项目，有着令人难以置信的非线性分支管理系统

## Git特性 ##

![图四 经典Git开发图示][_Git]  
**经典 Git开发过程图**

从一般开发者的角度来看：  
1. 从服务器上克隆完整的Git仓库到本机上。  
2. 在自己的机器上根据不同的开发目的，创建分支，修改代码。  
3. 在本机上自己创建的分支上提交代码。  
4. 在本机上合并分支。  
5. 把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。  
6. 生成补丁（patch），把补丁发送给主开发者。  
7. 看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。  
8. 一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。  
从主程的角度（假设主开发者不用开发代码）看:  
1、查看邮件或者通过其它方式查看一般开发者的提交状态。  
2、打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有用，哪些不用）。  
3、向公共服务器提交结果，然后通知所有开发人员。

## 特点 ##

1.  Git中每个克隆(clone)的版本库都是平等的。你可以从任何一个版本库的克隆来创建属于你自己的版本库，同时你的版本库也可以作为源提供给他人，只要你愿意。
2.  Git的每一次提取操作，实际上都是一次对代码仓库的完整备份。提交完全在本地完成，无须别人给你授权，你的版本库你作主，并且提交总是会成功。
3.  甚至基于旧版本的改动也可以成功提交，提交会基于旧的版本创建一个新的分支。
4.  Git的提交不会被打断，直到你的工作完全满意了，PUSH给他人或者他人PULL你的版本库，合并会发生在PULL和PUSH过程中，不能自动解决的冲突会提示您手工完成。
5.  冲突解决不再像是SVN一样的提交竞赛，而是在需要的时候才进行合并和冲突解决。

## Github ##

GitHub是一个通过Git进行版本控制的软件源代码托管服务。截止到2015年，GitHub已经有超过九百万注册用户和2110万代码库。事实上已经成为了世界上最大的代码存放网站和开源社区。

### github带来的好处 ###

我们都知道，很多大学的网站，比如我们学校，非常的丑陋。还有一些软件，比如计算机等级考试用的软件，非常的难用。问题的原因是什么？开发人员如果只在一个封闭的小世界中敲代码，往往在不知不觉间，手中的技术就变得陈腐不堪了。

放眼世界，注意那些日新月异的源代码、技术、设计以及文化，会对自己编写的源代码及成果带来巨大影响。GitHub 的出现已经让所有人平等拥有公开源代码的权利。看看Facebook 或Twitter 能了解一个人的品性，而看看GitHub 就能了解一个程序员的实力。

### github吉祥物 ###

![吉祥物][20161119100124224]  
*\* 图五 吉祥物\**

github拥有一只不知道是章鱼还是猫的吉祥物Octocat，非常有意思。网上有着不少种版本的故事来解释这个吉祥物的来历。  
虽然有各种美妙的版本来诠释 GitHub 吉祥物章鱼猫的涵义，但根据创始人 PJ Hyett 的说法，章鱼猫出自另一个创始人 Tom Preston-Werner 从一个图片网站花 50 美元买来的图片（当然，他们现在完全拥有这个形象），目的只是为 404 页面找一张有趣的图片。  
Octocat（章鱼猫）＝ Octopus（章鱼）+ Cat（猫）

### Github 和 Git 的关系 ###

提到Git，就自然会提到Github，那么Git和Github是什么关系？  
GitHub是一个通过Git进行版本控制的软件源代码托管服务。  
而Git只是一个开源的分布式版本控制系统。

# SVN 和 Git比较 #

1.  SVN属于集中化的版本控制系统，有个不太精确的比喻:SVN = 版本控制+ 备份服务器  
    Git是一个分布式版本控制系统。
2.  GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。
3.  GIT把内容按元数据方式存储，而SVN是按文件。  
    所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它们差距很大。因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。
4.  分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn propget svn:mergeinfo，来确认代码是否被合并。然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。
5.  GIT没有一个全局的版本号，而SVN有  
    目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道，SVN的版本号实际是任何一个相应时间的源代码快照。我认为它是从CVS进化到SVN的最大的一个突破。因为GIT和SVN从概念上就不同，我不知道GIT里是什么特征与之对应。如果你有任何的线索，请在评论里奉献出来与大家共享。
6.  GIT的内容完整性要优于SVN：  
    GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。

# 主要优缺点 #

SVN 的优缺点  
SVN对中文支持好，操作简单，使用没有难度，美工人员，产品人员，测试人员，实施人员都可轻松上手。使用界面统一，功能完善，操作方便。  
Git的优缺点  
对程序源代码进行差异化的版本管理，代码库占极少的空间。易于代码的分支化管理。不支持中文，图形界面支持差，使用难度大。不易推广。

# 总结 #

SVN更适用于项目管理， Git仅适用于代码管理。  
一个研发队伍的成员正常包括：需求分析、设计、美工、程序员、测试、实施、运维，每个成员在工作中都有产出物，包括了文档、设计代码、程序代码，这些都需要按项目集中进行管理的。SVN能清楚的按目录进行分类管理，使项目组的管理处于有序高效的状态。

Git更适合程序员们做一些开源项目来使用。  
若是开源项目，则git更加适合，每个人都可以维护自己专属的版本，同时有github开源社区支持。

[20161119095404338]: /images/20220715/b8a4085a013442e68d3a0cd700f22d15.png
[20161119095536060]: /images/20220715/6568c63c1fac439c8654338a27db0ccb.png
[20161119095646060]: /images/20220715/0ad4b87d67d148c89c4165ffa47801fc.png
[_Git]: /images/20220715/87eda3b454fd49c6ab5fd464a44b413e.png
[20161119100124224]: /images/20220715/7e0476d011b1403699c9411f4b99c432.png