Git和Subversion对比

看到Git的时候，不由自主的想到了Subversion，因为之前做项目的时候，这两个都有用过。话说目前我桌子上还有一本当时师兄给的Subversion的书，《版本控制之道——使用Subversion》，然而我并没有仔细翻看过，甚是惭愧。虽然当时只是用到一些比较基础的东西，并不熟练，但是初次使用它们进行版本控制，还是感觉神奇的不行，实在太省事了。
以前没有关注过这两个在版本控制方面有啥区别，现在查查资料总结如下。

1、 集中式与分布式

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

Git属于分布式的版本控制系统
Git记录版本历史只关心文件数据的整体是否发生变化。Git 并不保存文件内容前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一连接。工作方式如下图：

2、存储方式

Subversion是按文件存储内容
Git按元数据方式存储内容
所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn，.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它们差距很大。因为，.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。

3、版本库与工作区

Subversion 的版本库和工作区是分离的
Subversion的版本库和工作区是存储在不同路径下，一般是在不同的主机中，Subversion的企业级部署中，版本库在服务器上，只能通过 https, http, svn 等协议访问，而不能直接被用户接触到。
Git 的版本库和工作区如影随形
Git 的版本库和工作区在同一个目录下。 版本库可以脱离工作区而存在，成为 bare（赤裸）版本库。可以用 –bare 参数来创建。但是工作区不能脱离版本库而存在，即工作区的根目录下必须有一个名为 .git 的版本库克隆文件。版本库因为就在工作区中，能直接被用户接触到。

4、分支差异

分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，需要手工运行命令来确认代码是否被合并，经常会发生有些分支被遗漏的情况。
然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。

5、全局版本号和全球版本号

SVN的全局版本号和CVS的每个文件都独立维护一套版本号相比，是一个非常大的进步。在看似简单的全局版本号的背后，是Subversion提供对于事物处理的支持，每一个事物处理（即一次提交）都具有整个版本库全局唯一的版本号
Git的版本号则更进一步，版本号是全球唯一的。Git 对于每一次提交，通过对文件的内容或目录的结构计算出一个SHA-1 哈希值，得到一个40位的十六进制字符串，Git将此字符串作为版本号。

6、部分检出和全部检出

Subversion可以将整个库检出到工作区，也可以将某个目录检出到工作区。对于要使用一个庞大、臃肿的版本库的用户来说，部分检出是非常方便和实际的。
Git只能全部检出，不支持按照目录进行的部分检出。

7 、撤消操作

在Subversion中一旦完成向服务器的数据提交，你就没有办法再从客户端追回，只能在后续的提交中修正（回退或者修改）等。因为Subversion作为集中式的版本控制，不能允许个人对已提交的数据进行篡改。Subversion具有一个非常重要的特性就是它的信息从不丢失，即使当你删除了文件或目录，它也许从最新版本中消失了 ，但这个对象依然存在于历史的早期版本中。
Git则不同，Git是分布式版本控制系统，代码库是属于个人，允许任意修改。Git通过对提交建立数字摘要来保证提交的唯一性和不可更改性，通过版本库在多人之间的多份拷贝来保障数据的安全性。

虽然我对这两个都不是很熟，但从目前收集到的资料来看，各有优缺点吧，貌似Git更胜一筹。