前言

不知道什么是版本庫的，扇自己兩個大嘴巴；知道但不用的，扇自己四個大嘴巴?？焐热?。你真扇了？那你是個大傻瓜。扇什么扇，有扇自己的功夫，還不趕緊去用版本庫。

上面那句話是我根據(jù)《版本控制之道：使用Git》上一句讀者感言發(fā)展而來的。版本控制真的那么重要，真的那么好嗎？

什么是版本控制？

[此段寫給需要扇自己兩個大嘴巴的人，以及部分需要扇四個大嘴巴的人]

版本控制這個東西和許多控制規(guī)范等東西一樣，用明顯的、分散的、定量的、微小的、確定的效率降低，來換取偶然的、集中的、不確定的、嚴重的效率降低。OK，我承認這句話太唬人了。以后我爭取使用漢語普通話來說。其實我也不敢確定剛才那句話是否準確，但至少這是我的理解，很原創(chuàng)的。后面我會很負責人的解釋這句話的。

版本庫就是一個倉庫，你把東西放進去(通常是你編寫的程序代碼)，然后再在需要的時候拿出來。通常這種倉庫都有一個很神奇的地方，你不但能看到你放進去的東西現(xiàn)在的樣子，還能看到它以前的樣子，這就是版本了，同一件東西每次放進去時的樣子都會被保留下來，所以你可以追溯這個東西在任何時期的樣子。那么控制呢？那就有管理的概念在里面了。首先倉庫有自己的結(jié)構(gòu)(通常就是個數(shù)據(jù)庫)，進入倉庫的東西都按照這一結(jié)構(gòu)存放著，無論你把東西放進還是拿出也要遵循你所用倉庫的標準(用專用的版本控制命令或程序)，而依靠所提供的程序或命令，你就可以操作這個倉庫，控制里面的內(nèi)容，并且想看某個東西的任何某個版本都可以。

好的，我知道上面那一整段仍然很難理解，我們需要重來一遍。我們先說說什么東西能放到版本庫里并進行版本控制呢？通常版本控制是編程人員使用的，管理的是程序的代碼。所以版本庫首先就是個代碼庫。其次，每當代碼有了修改，編程人員就會把修改后的代碼再此提交到版本庫中。一次一次的，版本庫記錄就下了整個項目的代碼是如何一步步演化的。如果編程人員想看某段代碼以前的樣子，那么通過版本庫，編程人員可以從版本庫里找到曾經(jīng)這段代碼的每一個演化步驟。

更加簡明一些，首先是一個存放代碼的倉庫，其次是一套管理這個倉庫的工具，整個構(gòu)成了一套版本控制系統(tǒng)。

這一段大概就比較明確了。除了最常用的存放程序代碼，版本庫還可以存放許多其他的東西，比如這篇文章。這篇文章就是在Git版本控制系統(tǒng)的管理下。

有人會說，使用版本控制會影響效率，所以才不要用版本庫呢。[這是需要扇自己四個大嘴巴的人]OK，我先把內(nèi)容“提交”(commit)一下，然后再說這個問題。

版本控制表面上的確會影響效率。雖然當今的版本控制系統(tǒng)使用起來都比較簡單，但是仍然不可避免會花去一些學習的時間。為每個人安裝版本控制軟件也需要時間?？赡苓€要部署和維護一臺版本庫服務器，不但耗費時間還要花錢。寫點什么東西就需要提交，仍然需要花時間。然而這一且的花費怎么看也感覺沒有必要，并且也轉(zhuǎn)換不成最終的生產(chǎn)力。

為什么要力挺版本控制？

世界上無數(shù)大大小小的開發(fā)項目都在使用各種各樣的版本控制系統(tǒng)，原因在于它的優(yōu)點對于一個項目開發(fā)來說是無比重要。

一個最簡單的開發(fā)團隊，也許就兩三個人，他們共同完成一個軟件的開發(fā)。每個人都在修改、添加、刪除著自己本地硬盤上的代碼，當他們把這些代碼匯總起來時，麻煩出現(xiàn)了。到底誰改了哪些文件，具體是文件里的哪部分被改動過？A的修改會不會把B的修改覆蓋掉？匯總的工作變得很危險，需要非常小心，一旦出錯后果不堪設想。顯然此時，效率將會是無比的低下，如果某個地方出錯，可能整個匯總工作就要重來一遍。這只是兩三人的小團隊，如果是幾十人幾百人的大團隊呢？那將會是噩夢。

如果這個團隊采用了版本控制。那么版本控制軟件在每次提交的時候都會主動合并所有人的修改并解決可能發(fā)生的沖突。每個人手里一直都是匯總好的代碼。當開發(fā)進行到一定階段，可以直接拿去測試，不需要再有額外的工作來浪費時間。另外，你還可以知道，程序的某個Bug，是怎么出現(xiàn)的(被誰以及什么時候引入進來的)。

Subversion

上面的那些情況，我有幸親身經(jīng)歷過。很早以前我就聽說過版本控制這個東西，但當時我也認為使用版本控制純屬浪費時間沒事找事。但是后來我和我的同事兩人共同完成網(wǎng)站項目的時候，出現(xiàn)過多次把對方修改覆蓋掉的事情。最終，使我不得不考慮版本控制這個東西。我現(xiàn)在還清晰的記著年三十晚上抱著筆記本寫建立Subversion(SVN)版本庫方案的情景(其實不過是幾年前而已)，方案的主要內(nèi)容好像就是講述建立版本控制的必要性以及為什么選擇SVN。最終這份方案也沒有用到，春節(jié)過后我只是給我們的LQ領導說了一句(這一句其實還沒說完)，他就說只要有需要弄就可以。OK，很快SVN服務就在一臺現(xiàn)有的Windows Server 2003服務器(所以說沒幾年時間)上搭建起來并開始使用了。那份方案后來我就沒再見過，不知道放哪里去了。

當時，CVS和SVN是我的兩個候選，最首先的原因就是開源(如果是商業(yè)性的，那么最終只可能去用盜版，這是我不希望看到的)。CVS是非常經(jīng)典的，當時許多人都在使用，CVS的教程和文檔我也看了很多。但最終我選擇了SVN，大概是因為許多項目都從CVS轉(zhuǎn)向SVN，其次是有個Subversion中文站翻譯的很好的中文教程，還有就是在Windows下有一個很好用的TortoiseSVN。反過來，放棄CVS的直接原因就是CVS比SVN難用了。

這個SVN一直用到現(xiàn)在(同樣其實也沒幾年)，效果是非常好的。兩個人都可以自由的編輯修改文件內(nèi)容，卻不用考慮另一個人在干什么，大不了發(fā)生沖突的時候自己簡單改改就可以了，而且出現(xiàn)沖突的次數(shù)屈指可數(shù)。所以，我的想法發(fā)生了徹底得改變。前面說了，以前我認為用版本控制是浪費時間沒事找事，現(xiàn)在我認為多人開發(fā)團隊不用版本控制屬于給整個團隊找麻煩，團隊管理者需要扇自己四個大嘴巴。所以當知道我的同事所在的新單位沒有使用版本控制的時候，我是非常驚訝。是的，我的那位同事去年跳槽走了。

當然，在使用SVN時還是出了一些小不足。我們所搭建的結(jié)構(gòu)是所有項目都放在同一個版本庫下(不同路徑)，因為全都是網(wǎng)站項目，所以這是一種很省事并且好維護的方式，但后來發(fā)現(xiàn)也挺影響性能的，只是還在容忍范圍內(nèi)。不過還是存在一些有趣的事情，Windows XP與Windows Server間明顯比Linux(用RapidSVN)與Windows Server間慢。原因不明，不過我沒有深究?？紤]SVN在Windows下也是原生程序，不應該差別如此明顯，也許是Windows自身對目錄等操作的效率引起的吧。

版本控制選擇

一個團隊，選擇什么樣的版本控制系統(tǒng)，是需要深思熟慮的。如果版本控制建立起來了，再改換其他那會是相當麻煩。如果整個團隊都在使用某個IDE(集成開發(fā)環(huán)境)，那么用IDE內(nèi)置的版本控制(許多IDE都會帶)是比較好的選擇，原因就是和IDE自身銜接緊密。有些IDE(例如Eclipse)可以通過插件使用多種版本控制系統(tǒng)，以及像我們這樣用的工具比較雜通常就用個記事本(有些夸張，我們基本是用notepad++，我在Linux下用Geany)的人，怎么選擇用什么樣的版本控制系統(tǒng)呢？我認為可以考慮如下幾個方面：

1.大家都用什么操作系統(tǒng)，要選擇在這個操作系統(tǒng)下速度快的版本控制系統(tǒng)；

2.上手要容易，團隊的許多成員可能并不想費力去學習一個表面上看純屬浪費時間的東西，所以能讓他們用最少的時間掌握非常重要，哪怕你可以用高壓手段逼迫他們學習，但到用的時候簡單易用仍然能減少許多不必要的麻煩，畢竟版本庫仍然有可能被不懂操作的人弄得一塌糊涂；

3.最適合自己項目以及團隊組織形式的版本控制系統(tǒng)。

目前大家最常用的版本控制系統(tǒng)有哪些呢？下面我也簡單說說，當然版本控制非常多，我也只知道下面幾個，而且都是開源的。

前面提到過的一個叫CVS的，這個很有名，目前可能依然有人用，不過建議大家就不要再考慮了。原因就是太老了，沒有人再維護這個東西了，只做紀念了。

前面提到的Subversion，非常流行的一套系統(tǒng)，也是我們(很不幸目前只有我一人了)在用的。Google Code等項目托管站點也在使用。wikipedia中文上列出了一些使用SVN的項目，不過許多項目好像已經(jīng)遷移到了git上。無論如何，SVN是集中式版本控制的典范，非常優(yōu)秀。

分布式版本控制系統(tǒng)

下面是兩個十分有名的分布式版本控制系統(tǒng)。剛才說到SVN是集中式，現(xiàn)在只簡單提一句。集中與分布有一個明顯的區(qū)別，集中式的版本庫數(shù)據(jù)只存在于服務器上(服務器是必須存在的)，而分布式的版本庫信息存在于每一個開發(fā)者的機器上(不一定必須有個服務器)。

Mercurial

Mercurial是目前非常流行的分布式版本控制系統(tǒng)，命令是hg(汞)。Google Code也支持Mercurial，建立項目的時候可以在Mercurial和Subversion之間選擇一個。使用Mercurial的其他項目也不少，當你看到要用hg clone命令下載某個項目源碼的時候，你就知道這個項目使用Mercurial來管理了。我很坦白，這個東西我沒用過，只用hg clone下載過源代碼。

git

由Linux內(nèi)核的創(chuàng)造者Linus Torvalds所創(chuàng)造的git，是一個概念非常先進的完全分布式版本控制系統(tǒng)。當你用git clone下載項目源代碼的時候，你就知道它的存在了。最初開發(fā)git的目的是為了管理Linux內(nèi)核的開發(fā)，但現(xiàn)在有許多著名項目已經(jīng)轉(zhuǎn)到了git(見git官網(wǎng)首頁)。git有著非常多的優(yōu)點，比如剛才說到的完全分布式，這使得git完全不需要服務器(Mercurial好似沒能做到這點)。非常高效的分支，建立、合并分支幾乎可以瞬間完成，所以git推薦用戶大量使用分支。另外依靠上面兩個優(yōu)點，使得它可以實現(xiàn)非常靈活的組織形式，從幾人小團隊到像Linux開發(fā)那樣的龐大團隊都能找到最適合自己的組織形式。

git提供非常好的SVN兼容工具，可以把SVN版本庫遷移到git版本庫(這也許就是許多過去用SVN的項目轉(zhuǎn)向git的原因吧)，或者是在git和SVN混合狀態(tài)下使用(很有意思的結(jié)構(gòu)，本地git整體SVN，可以解決許多問題)。不過git也有一些比較明顯的缺點。有人說命令比較多，上手比較困難(實際上常用命令也就那么幾個)。沒有好的圖形界面程序，基本只能大量用命令。目前沒有原生的Windows程序，只有通過minGW的實現(xiàn)，速度就比較慢了。

大家也許會發(fā)現(xiàn)，介紹git的那一段我寫了許多。那是因為我現(xiàn)在正在使用git。SVN讓我了解到團隊合作使用版本控制是必須的，而git讓我充分了解到哪怕自己一個人做項目版本控制仍然是必要的(雖然在用git之前我已經(jīng)用svn管理自己個人的項目，也就是目前大家所在的這個網(wǎng)站，但那時候我不會給別人推薦這種做法)。哪一點是必要的呢？保證代碼的安全。版本庫依舊是記錄你個人的每次提交，所以你可以追溯代碼的改變，找回以前認為沒有用但現(xiàn)在又突然有用的代碼。如果用集中式版本控制，你需要建一個版本庫和一個工作目錄，這對個人來說顯然就非常繁瑣了。而git這種完全分布式，版本庫和工作目錄都在一起，一條命令建立完成，使用速度非?？?。

另外git可以使組織結(jié)構(gòu)非常靈活，雖然它不需要有服務器，但是它仍然可以有服務器。我用一臺淘汰下來的筆記本電腦配置了一臺簡易服務器(我別的文章上提過)，上面就有用gitosis-admin管理著的git版本庫。我的臺式機和其他筆記本最終都把數(shù)據(jù)“推”(push)到那里統(tǒng)一存放。大家所看到的這個網(wǎng)站，我也使用git自帶的遷移工具從SVN轉(zhuǎn)到了git。

總結(jié)

扯了許多亂七八糟了，怎么看都有跑題的感覺。最后總結(jié)一下。版本控制好處多多，不知道版本控制的人需要多多了解一下，知道版本控制卻不去使用的人應該努力改變自己的想法。版本控制帶來的好處真的是太多了。

以上就是使用版本控制原因及Git與Subversion介紹的詳細內(nèi)容，更多關于Git 與Subversion版本控制的資料請關注腳本之家其它相關文章！