對(duì)比SVN學(xué)習(xí)GIT版本管理工具
作者：劉旭暉 Raymond轉(zhuǎn)載請(qǐng)注明出處
Email：colorant@163.com
BLOG：http://blog.csdn.net/colorant/
主頁(yè)：http://sites.google.com/site/rgbbones/
因?yàn)榻诠ぷ餍枰?，要掌?/span>git的使用方法，所以決心花點(diǎn)時(shí)間學(xué)習(xí)一下它的各種使用方法，就當(dāng)是花點(diǎn)時(shí)間磨刀吧。所以寫這篇文檔的目的主要還是為了自己能夠系統(tǒng)的學(xué)習(xí)和理解GIT應(yīng)用的方方面面，因?yàn)橹皩?duì)SVN算是比較熟悉，所以決定以概念對(duì)比的方式來(lái)整理這篇文章，盡管，有些地方兩者無(wú)法直接比較 8 ）此外，主要的目的還是為了方便自己積累相關(guān)的git使用技巧。文中理解有偏差的地方，還請(qǐng)大家指正。
http://www.kernel.org/pub/software/scm/git/docs/
這里面包括了 tutorial 基本的操作 / core-tutorial 底層命令的使用 / user’s manual 完整的用戶手冊(cè)以及其它各種資料，如果你看完了，我的這篇文檔你也就不用看了。
http://svnbook.red-bean.com/ 這里是一份online的svn book
或者也可以看tortoiseSVN的幫助文檔
倉(cāng)庫(kù)的組織管理形式這部分，應(yīng)該說(shuō)是版本管理工具設(shè)計(jì)上最核心的內(nèi)容。對(duì)于倉(cāng)庫(kù)的內(nèi)部管理機(jī)制，我了解得很少，只能從外部的表象上做一些簡(jiǎn)單的比較。
SVN屬于中心式的倉(cāng)庫(kù)管理，完整的倉(cāng)庫(kù)數(shù)據(jù)，統(tǒng)一維護(hù)在服務(wù)器端的（當(dāng)然，服務(wù)器也可以就是你的本機(jī)了）倉(cāng)庫(kù)中，對(duì)于客戶端來(lái)說(shuō)，本地取得的數(shù)據(jù)不是完整的倉(cāng)庫(kù)，只是倉(cāng)庫(kù)中特定版本的部分或全部數(shù)據(jù)，同時(shí)，客戶端還負(fù)責(zé)維護(hù)本地?cái)?shù)據(jù)的變更情況，在客戶端并不擁有倉(cāng)庫(kù)完整的歷史數(shù)據(jù)。本地的工作樹和倉(cāng)庫(kù)是相對(duì)獨(dú)立的。
對(duì)于Git來(lái)說(shuō)，應(yīng)該屬于分布式的倉(cāng)庫(kù)管理，倒不是說(shuō)倉(cāng)庫(kù)的內(nèi)容分散在不同的server上，只是對(duì)倉(cāng)庫(kù)而言，沒(méi)有中心倉(cāng)庫(kù)之說(shuō)，所有的倉(cāng)庫(kù)都是平等的。對(duì)于一個(gè)倉(cāng)庫(kù)的不同工作拷貝，每個(gè)都擁有完整的歷史數(shù)據(jù)，工作樹和倉(cāng)庫(kù)基本是合二為一的。
在SVN中，從倉(cāng)庫(kù)checkout的一個(gè)工作樹，每個(gè)子目錄下都維護(hù)著自己的.svn目錄，記錄著該目錄中文件的修改情況以及和服務(wù)器端倉(cāng)庫(kù)的對(duì)應(yīng)關(guān)系。所以SVN可以局部checkout部分路徑下的內(nèi)容，而不用checkout整個(gè)分支。
Git倉(cāng)庫(kù)中，項(xiàng)目根目錄下的.git目錄統(tǒng)一管理了所有的倉(cāng)庫(kù)數(shù)據(jù)和當(dāng)前工作樹的相關(guān)信息。
在SVN中，默認(rèn)采用FSFS的數(shù)據(jù)庫(kù)格式，任何提交都是一個(gè)版本的遞增，所謂分支，tag等概念都只是倉(cāng)庫(kù)中不同路徑上的一個(gè)對(duì)象或索引而已，和普通的路徑并沒(méi)有本質(zhì)的區(qū)別。在工作樹中，可以同時(shí)checkout多個(gè)分支的內(nèi)容。
在Git中，其內(nèi)部的對(duì)象層級(jí)依賴關(guān)系或許和SVN類似，但是其工作樹的視圖表現(xiàn)形式和SVN完全不同。工作樹永遠(yuǎn)是一個(gè)完整的分支，不同的分支由不同的head索引去構(gòu)建，你不可能在工作樹中同時(shí)獲得多個(gè)分支的內(nèi)容。
在SVN中，倉(cāng)庫(kù)本身的管理和日常應(yīng)用，使用的是兩套不同的命令。倉(cāng)庫(kù)的創(chuàng)建和備份維護(hù)等使用的命令是 svnadmin， 使用svnadmin create來(lái)創(chuàng)建一個(gè)新的倉(cāng)庫(kù)
在git中，創(chuàng)建一個(gè)新的倉(cāng)庫(kù)，可以在一個(gè)空目錄下，使用git init來(lái)實(shí)現(xiàn)，它將創(chuàng)建一個(gè).git目錄用來(lái)維護(hù)倉(cāng)庫(kù)數(shù)據(jù)。
在SVN中，創(chuàng)建倉(cāng)庫(kù)的地方并不是你日常使用的倉(cāng)庫(kù)的地方，你需要在別的地方checkout出特定的倉(cāng)庫(kù)路徑作為你的日常工作的目錄。在git中，倉(cāng)庫(kù)所在的目錄也就是你的日常工作目錄，沒(méi)有服務(wù)器端和客戶端之分。（嚴(yán)格的說(shuō) .git目錄才是倉(cāng)庫(kù)，.git目錄外的地方是你的工作目錄，對(duì)于bare project來(lái)說(shuō)，只有git目錄下的內(nèi)容，工作目錄離得內(nèi)容還是要checkout出來(lái)的）
在SVN中，使用SVN checkout(co)來(lái)checkout本地或遠(yuǎn)程倉(cāng)庫(kù)的代碼
而對(duì)于git來(lái)說(shuō)，盡管也有checkout命令，但是由于你需要在本地?fù)碛袀}(cāng)庫(kù)，所以通常從服務(wù)器上checkout代碼的第一步是使用git clone來(lái)獲取一個(gè)倉(cāng)庫(kù)的拷貝，默認(rèn)的git clone操作同時(shí)還會(huì)checkout一份遠(yuǎn)程倉(cāng)庫(kù)上當(dāng)前active的分支
在SVN中，其倉(cāng)庫(kù)的管理形式?jīng)Q定了你可以只checkout倉(cāng)庫(kù)中特定路徑/分支下的子目錄，而不是整個(gè)倉(cāng)庫(kù)，而git只能checkout整個(gè)分支。
在SVN中，使用SVN add，這樣在以后的commit過(guò)程中，每次在提交數(shù)據(jù)之前，svn都會(huì)自動(dòng)根據(jù)這些add過(guò)的對(duì)象的修改情況，構(gòu)建一個(gè)commit tree。
在git中，因?yàn)榇嬖?/span>index的概念，要將一個(gè)文件納入版本管理的范疇，首先是要用git-update-index –-add將文件納入index的監(jiān)控范圍，只有更新到index中的內(nèi)容才會(huì)在commit的時(shí)候被提交。另外，文件本身的改動(dòng)并不會(huì)自動(dòng)更新到index中，每次的任何修改都必須重新更新到index中去才會(huì)被提交。 當(dāng)然，通常會(huì)用git add這樣的封裝腳本來(lái)調(diào)用git-update-index
SVN Status 可以顯示當(dāng)前working tree的文件修改狀態(tài)
在git中 git status 命令顯示當(dāng)前index的狀態(tài)和working tree的狀態(tài)。
Git commit操作在git命令中屬于相對(duì)簡(jiǎn)單的，需要注意的一點(diǎn)就是上面提到的，只有index中的內(nèi)容才會(huì)比提交。
在使用Svn rm刪除一個(gè)目錄的時(shí)候，因?yàn)槊總€(gè)目錄下都存在.svn目錄，記錄了這個(gè)目錄于服務(wù)器端倉(cāng)庫(kù)相關(guān)的信息，所以在commit之前，目錄里的其它文件會(huì)被刪除，但是目錄及其子目錄并不會(huì)被真正刪除，只有commit以后，目錄才會(huì)被刪除。
在git中，同樣，使用git rm 刪除文件。但是git對(duì)目錄的處理有些奇怪，如果某個(gè)目錄下的所有文件都被刪除以后，該目錄就會(huì)被自動(dòng)刪除，也就是說(shuō)你無(wú)法保留一個(gè)空的目錄。你也無(wú)法添加一個(gè)空目錄到倉(cāng)庫(kù)里。也就是說(shuō)git 自動(dòng)忽略空目錄，不知道這樣做的目的是什么？
svn log命令基本上就是用來(lái)查看版本提交時(shí)的所填寫的log信息
git log可以做的事情會(huì)多很多，畢竟git log是對(duì)底層核心命令的再包裝，通過(guò)它，不僅可以查看log信息，還可以輸出特定版本的具體變更內(nèi)容等等信息。
在SVN中，不提供任何從倉(cāng)庫(kù)中刪除對(duì)象的機(jī)制，任何的修改都會(huì)導(dǎo)致版本的遞增，所以，如果想丟棄一個(gè)修改，你需要做的事是反向diff你的修改，再提交一個(gè)新的版本。
在git中提供了重置committed tree對(duì)象索引的機(jī)制，所以，你可以通過(guò)例如git-reset這樣的操作將當(dāng)前分支的版本恢復(fù)到以前的某個(gè)狀態(tài)。經(jīng)?？匆姷睦泳褪腔厮菀粋€(gè)版本，然后修改內(nèi)容，再次提交。不過(guò)這樣做搞不好很容易出問(wèn)題。包括在git-push之類的操作時(shí)會(huì)被reject，需要強(qiáng)行push之類的。
如果只是想放棄一個(gè)修改，git的文檔推薦使用git-revert操作，這個(gè)操作基本上和SVN的思路是一樣的了，就是提交一個(gè)新的版本將需要revert的版本的內(nèi)容再反向修改回去，版本會(huì)遞增，不影響之前提交的內(nèi)容。
在SVN中，使用SVN revert對(duì)目錄或文件操作都可以將當(dāng)前工作樹上特定路徑的修改恢復(fù)到服務(wù)器上的版本，放棄當(dāng)前的修改。
Git中，對(duì)特定文件使用不帶其它參數(shù)的git checkout命令可以將文件恢復(fù)到index中的狀態(tài)，如果你想恢復(fù)的特定的版本，那么類似： git checkout HEAD file這樣的操作，將文件恢復(fù)到HEAD tree即最近一次提交的狀態(tài)。
不過(guò)git checkout有個(gè)問(wèn)題，不知道是否是故意這樣設(shè)計(jì)的，就是即使用git rm刪除的內(nèi)容，如果沒(méi)有提交，git checkout以后也會(huì)恢復(fù)，包括它在index中的狀態(tài)。這點(diǎn)有些不理解。 理論上index上已經(jīng)記錄這個(gè)刪除操作，不應(yīng)該恢復(fù)才對(duì)。
Git中還有一種辦法，可以快速?gòu)氐椎姆艞壸詮纳洗?/span>commit以來(lái)的所有變更，git reset –hard HEAD
git merge能夠自動(dòng)記住以前merge過(guò)的位置和狀態(tài)，這個(gè)比較容易理解，因?yàn)橥ㄟ^(guò)每個(gè)分支的head commit可以跟蹤它的對(duì)象索引關(guān)系。另外，因?yàn)槠鋵?duì)象管理機(jī)制的原因，只能以commit為單位，merge整個(gè)分支的所有修改。不能有選擇的merge部分路徑下的修改。Merge的時(shí)候要求index和HEAD是一致的，如果merge成功，內(nèi)容會(huì)直接commit，而工作樹上的修改仍會(huì)保持。（如果失敗，會(huì)在工作樹上將需要merge的內(nèi)容和你已有的修改合并，大概不是你所希望的，所以最好不要這樣做）
merge特定分支的特定版本之前的所有修改，可以通過(guò)merge那個(gè)版本對(duì)應(yīng)的rev來(lái)實(shí)現(xiàn)，merge某一段版本區(qū)間的修改，考慮到commit需要完整的代碼樹關(guān)系，估計(jì)靠git merge來(lái)做是沒(méi)有辦法了，需要自己diff / patch代碼來(lái)實(shí)現(xiàn)
SVN的Merge操作不會(huì)記住它的merge歷史，換句話說(shuō)，你可以多次merge同一份代碼，但是他的好處是你可以自由的選擇merge哪一部分、哪一段版本之間的代碼，應(yīng)該說(shuō)他基本等同于是diff和patch的組合。不過(guò)因?yàn)?/span>SVN沒(méi)有index的概念，所以merge的操作會(huì)和當(dāng)前working tree上的修改合并在一起。
關(guān)于歷史信息方面，因?yàn)?/span>svn的merge實(shí)際是patch文件內(nèi)容本身，所以，不同分支上的歷史信息不會(huì)在merge以后的主干上體現(xiàn)出來(lái)，而git的merge，如果沒(méi)有沖突的話，實(shí)際是merge commit樹的繼承關(guān)系，所以，所有的歷史信息在merge以后的commit中都能夠被索引到。
在svn中，如果不需要任何歷史信息，只想要某個(gè)版本純粹的代碼（經(jīng)常會(huì)有這種需求，這樣做本地?cái)?shù)據(jù)比較?。?/span> 那么，使用svn export命令即可以實(shí)現(xiàn)。
在git中，似乎沒(méi)有這樣的命令，不過(guò)，由于git的本地倉(cāng)庫(kù)信息完全維護(hù)在project根目錄的.git目錄下，（不像svn一樣，每個(gè)子目錄下都有單獨(dú)的.svn目錄）。所以，只要clone，checkout然后刪除.git目錄就可以了。
對(duì)于SVN來(lái)說(shuō)，由于是中心式的倉(cāng)庫(kù)管理形式，所以并不存在特殊的遠(yuǎn)程提交的概念，所有的commit操作都可以認(rèn)為是對(duì)遠(yuǎn)程倉(cāng)庫(kù)的更新動(dòng)作。
在git中，因?yàn)橛斜镜貍}(cāng)庫(kù)和remote倉(cāng)庫(kù)之分，所以也就區(qū)別于commit 操作，存在額外的push命令，用于將本地倉(cāng)庫(kù)的數(shù)據(jù)更新到遠(yuǎn)程倉(cāng)庫(kù)中去。這種工作模式應(yīng)該是大多數(shù)開源項(xiàng)目的維護(hù)者的工作模式之一。
git push 可以選擇需要提交的更新的分支以及制定該分支在遠(yuǎn)程倉(cāng)庫(kù)上的名字。
在SVN中，因?yàn)橹挥幸粋€(gè)中心倉(cāng)庫(kù)，所以所謂的遠(yuǎn)程更新，也就是svn update
對(duì)于git來(lái)說(shuō)，別人的改動(dòng)是存在于遠(yuǎn)程倉(cāng)庫(kù)上的，所以git checkout命令盡管在某些功能上和svn中的update類似（例如取倉(cāng)庫(kù)特定版本的內(nèi)容），但是在遠(yuǎn)程更新這一點(diǎn)上，還是不同的，不屬于git checkout的功能涵蓋范圍
Git使用git fetch和git pull來(lái)完成遠(yuǎn)程更新任務(wù)，fetch操作只是將遠(yuǎn)程數(shù)據(jù)庫(kù)的object拷貝到本地，然后更新remotes head的refs，git pull 的操作則是在git fetch的基礎(chǔ)上對(duì)當(dāng)前分支外加merge操作。
SVN中，我很喜歡的一個(gè)功能就是switch，使用Switch可以在同一個(gè)工作樹上，對(duì)不同的模塊checkout不同分支上的代碼。 舉個(gè)例子： 我從主干上checkout了整個(gè)內(nèi)核樹，然后使用switch命令將其中一個(gè)或幾個(gè)驅(qū)動(dòng)的目錄或文件切換到我的個(gè)人分支或其它人的分支上去，這樣，我可以使用一個(gè)update命令同時(shí)從幾個(gè)不同的來(lái)源更新特定的文件，而我在工作樹上對(duì)switch過(guò)的文件做的修改會(huì)自動(dòng)提交到我的個(gè)人分支上，而不是主干的路徑上。這樣我的修改不會(huì)影響主干的內(nèi)容，而同時(shí)又能隨時(shí)更新主干上的最新內(nèi)容。不僅方便工作，也有利于權(quán)限控制。一切都是自動(dòng)的，方便！
在Git中，盡管也可以使用checkout命令checkout 特定分支的特定文件到當(dāng)前分支的工作樹上, 但是，這只是簡(jiǎn)單的更新當(dāng)前工作樹的文件內(nèi)容而已，這些文件并不會(huì)被關(guān)聯(lián)到他的來(lái)源上去，也就是說(shuō)你做的任何修改，還是針對(duì)當(dāng)前分支的。
對(duì)于多分枝協(xié)同工作，我所見到的常見的工作模式是fetch遠(yuǎn)程更新，然后merge到當(dāng)前分支。這對(duì)于維護(hù)會(huì)沖突的不同版本和快速切換局部分支顯然還是有所不足的。
這種情況或許和git的分布式倉(cāng)庫(kù)結(jié)構(gòu)和整體設(shè)計(jì)思路有關(guān)，或許這樣有利于保持所有開發(fā)者之間的代碼的同步，但是總覺(jué)得這是個(gè)遺憾，這方面沒(méi)有深入的再去研究，或許通過(guò)borrow object的方式可以部分實(shí)現(xiàn)類似SVN的switch的功能？（也或許要實(shí)現(xiàn)多分枝協(xié)同工作，在Git中還有其它不同思路的更巧妙的辦法？） 哪位高手知道解決辦法的還請(qǐng)不吝賜教！
git submodules 看起來(lái)是為了解決類似多個(gè)有依賴關(guān)系的模塊的協(xié)同工作問(wèn)題。不過(guò)用起來(lái)似乎有不少限制和麻煩。
對(duì)于git協(xié)同工作時(shí)的權(quán)限控制，還沒(méi)有仔細(xì)研究，不知道能否像SVN那樣，通過(guò)Apache的用戶賬號(hào)形式，對(duì)每一個(gè)用戶精確控制到文件級(jí)別的讀寫權(quán)限。 目前初步查找了一下，看來(lái)似乎沒(méi)有這樣的功能，不知道設(shè)計(jì)的初衷是什么，對(duì)于小組開發(fā)來(lái)說(shuō)或許會(huì)比較麻煩？
這個(gè)與開源精神應(yīng)該沒(méi)有太直接的關(guān)系才對(duì)，因?yàn)楹芏鄷r(shí)候，其實(shí)權(quán)限控制的目的倒不是純粹為了限制對(duì)代碼的Access，主要還是為了減少代碼沖突，減少誤操作等情況的發(fā)生。
丟失版本最常見的問(wèn)題就是 比如使用了 git reset –hard HEAD^之類的操作，結(jié)果發(fā)現(xiàn)丟棄的版本還想恢復(fù)回來(lái)，但是已經(jīng)沒(méi)有任何分支能夠reference到這個(gè)commit了。幸運(yùn)的是，git 對(duì)各個(gè)分支的head還有一份log記錄叫做reflog，你可以在.git/logs/refs/head/ 目錄下看到他們。 通過(guò) git reflog可以顯示變更歷史。使用類似 master@{1} master@{“2 days ago”}之類的格式，就能索引到你想要的commit。例如對(duì)應(yīng)于git reset –hard HEAD^ 使用 git reset --hard HEAD@{1}即可恢復(fù)到reset之前的commit上。
如果只是想對(duì)最近一次的提交做一些變更，但是不想在commit tree上遞增版本的話，可以使用git commit –amend來(lái)實(shí)現(xiàn)，在現(xiàn)有的基礎(chǔ)上做任何你想做的變更，然后用帶–amend參數(shù)的commit命令提交即可?；旧希@個(gè)操作近似等同于于以下操作：
$ git reset --soft HEAD^
$ ... do something else to come up with the right tree ...
$ git commit -c ORIG_HEAD
和git reset之類的操作類似，對(duì)于已經(jīng)push的內(nèi)容，最好是不要做這些回滾的操作，因?yàn)閷?shí)際上，原先commit的head還是存在的，新的head和以前的head沒(méi)有繼承關(guān)系，在協(xié)同工作的時(shí)候容易產(chǎn)生一些問(wèn)題（我猜想主要是merge相關(guān)的操作吧，因?yàn)?/span>merge是根據(jù)對(duì)象的繼承關(guān)系來(lái)自動(dòng)判斷需要merge的內(nèi)容的，對(duì)于已經(jīng)merge過(guò)的分支被回滾以后，可能無(wú)法自動(dòng)區(qū)別識(shí)別出這部分內(nèi)容應(yīng)該如何處理）
聯(lián)系客服
