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 的版本庫是很容易的事。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章