GIT和SVN之间的五个基本区别

如果你在读这篇文章，说明你跟大多数开发者一样对GIT感兴趣，如果你还没有机会来试一试GIT，我想现在你就要了解它了。

GIT不仅仅是个版本控制系统，它也是个内容管理系统(CMS),工作管理系统等。如果你是一个具有使用SVN背景的人，你需要做一定的思想转换，来适应GIT提供的一些概念和特征。所以，这篇文章的主要目的就是通过介绍GIT能做什么、它和SVN在深层次上究竟有什么不同来帮助你认识它。

那好，这就开始吧…

1. GIT是分布式的，SVN不是：

   这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。如果你能理解这个概念，那么你就已经上手一半了。需要做一点声明，GIT并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如Bitkeeper, Mercurial等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。

   GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。

   同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。GitHub.com就是一个这样的优秀案例。

   有些谣言传出来说subversion将来的版本也会基于分布式模式。但至少目前还看不出来。

2. GIT把内容按元数据方式存储，而SVN是按文件：

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

3. GIT分支和SVN的分支不同：

   分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn propget svn:mergeinfo，来确认代码是否被合并。感谢Ben同学指出这个特征。所以，经常会发生有些分支被遗漏的情况。

   然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。

4. GIT没有一个全局的版本号，而SVN有：

   目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道，SVN的版本号实际是任何一个相应时间的源代码快照。我认为它是从CVS进化到SVN的最大的一个突破。因为GIT和SVN从概念上就不同，我不知道GIT里是什么特征与之对应。如果你有任何的线索，请在评论里奉献出来与大家共享。

   更新：有些读者指出，我们可以使用GIT的SHA-1来唯一的标识一个代码快照。这个并不能完全的代替SVN里容易阅读的数字版本号。但，用途应该是相同的。

5. GIT的内容完整性要优于SVN：

   GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。这里有一个很好的关于GIT内容完整性的讨论 –http://stackoverflow.com/questions/964331/git-file-integrity

GIT和SVN之间只有这五处不同吗？当然不是。我想这5个只是“最基本的”和“最吸引人”的，我只想到这5点。如果你发现有比这5点更有趣的，请共享出来，欢迎。

我是一開始就用Mercurial, Git這類的系統。（現在已經百分百用Git了。）
用過Git之後才接觸SVN，發現了一些非常大的差別。在這裡提出我個人一些主要理由為何棄SVN而用Git。

1。速度：
克隆一份全新的目錄，以同樣擁有五個（才五個）分支來說，SVN是同時複製5個版本的文件，也就是說重複五次同樣的動作。而Git只是獲取文件的每個版本的元素，然後只載入主要的分支（master）。在我的經驗，克隆一個擁有將近一萬個提交（commit），五個分支，每個分支有大約1500個文件的SVN，耗了將近一個小時！而Git只用了區區的1分鐘！

2。版本庫（repository）：
據我所知，SVN只能有一個指定中央版本庫。當這個中央版本庫有問題時，所有工作成員都一起癱瘓直到版本庫維修完畢或者新的版本庫設立完成。

而Git可以有無限個版本庫。或者，更正確的說法，每一個Git都是一個版本庫，區別是它們是否擁有活躍目錄（Git Working Tree）。如果主要版本庫（例如：置於GitHub的版本庫）發生了什麼事，工作成員仍然可以在自己的本地版本庫（local repository）提交，等待主要版本庫恢復即可。工作成員也可以提交到其他的版本庫！

3。分支（Branch）
在SVN，分支是一個完整的目錄。且這個目錄擁有完整的實際文件。如果工作成員想要開啟新的分支，那將會影響“全世界”！每個人都會擁有和你一樣的分支。如果你的分支是用來進行破壞工作（安檢測試），那將會像傳染病一樣。

而Git，每個工作成員可以任意在自己的本地版本庫開啟無限個分支。舉例：當我想嘗試破壞自己的程序（安檢測試），並且想保留這些被修改的文件供日後使用，我可以開一個分支，做我喜歡的事。完全不需擔心妨礙其他工作成員。只要我不合并及提交到主要版本庫，沒有一個工作成員會被影響。等到我不需要這個分支時，我只要把它從我的本地版本庫刪除即可。無痛無癢。
Git的分支名是可以使用不同名字的。例如：我的本地分支名為testing，而在主要版本庫的名字其實是master。
最值得一提，我可以在Git的任意一個提交點（commit point）開啟分支！（其中一個方法是使用gitk –all 可觀察整個提交記錄，然後在任意點開啟分支。）

4。提交（Commit）
在SVN，當你提交你的完成品時，它將直接記錄到中央版本庫。當你發現你的完成品存在嚴重問題時，你已經無法阻止事情的發生了。如果網路中斷，你根本沒辦法提交！

而Git的提交完全屬於本地版本庫的活動。而你只需“推”（git push）到主要版本庫即可。Git的“推”其實是在執行“同步”（Sync）。

5。重新設立起點（Rebase）
我沒在SVN嘗試過，不知道有沒有這樣的功能。

在Git，如果你想把別人的最新提交設立為現在這個分支的起點，只要執行git rebase branch_name 即可。這個和合并（merge）不同點是，merge會依據修改的時間視為最新，而Rebase會要求你去解決雙方都有修改過的地方的矛盾（conflict）。

A - B - E
- C - D
A - B - E
- C - D


6。系統檔案
SVN會在每一個目錄置放一個.svn。如果想移除這些.svn是很累的。
而Git會在目錄起點擁有一個.git目錄，以及.gitignore。

對我而言，管理一個Git 的版本庫是很容易的事。