一、集中式vs分布式

1.Subversion屬于集中式的版本控制系統(tǒng)

集中式的版本控制系統(tǒng)都有一個(gè)單一的集中管理的服務(wù)器，保存所有文件的修訂版本，而協(xié)同工作的人們都通過客戶端連到這臺(tái)服務(wù)器，取出最新的文件或者提交更新。

Subversion的特點(diǎn)概括起來主要由以下幾條：

• 每個(gè)版本庫(kù)有唯一的URL（官方地址），每個(gè)用戶都從這個(gè)地址獲取代碼和數(shù)據(jù)；
• 獲取代碼的更新，也只能連接到這個(gè)唯一的版本庫(kù)，同步以取得最新數(shù)據(jù)；
• 提交必須有網(wǎng)絡(luò)連接（非本地版本庫(kù)）；
• 提交需要授權(quán)，如果沒有寫權(quán)限，提交會(huì)失??；
• 提交并非每次都能夠成功。如果有其他人先于你提交，會(huì)提示“改動(dòng)基于過時(shí)的版本，先更新再提交”… 諸如此類；
• 沖突解決是一個(gè)提交速度的競(jìng)賽：手快者，先提交，平安無事；手慢者，后提交，可能遇到麻煩的沖突解決。

好處：

每個(gè)人都可以一定程度上看到項(xiàng)目中的其他人正在做些什么。而管理員也可以輕松掌控每個(gè)開發(fā)者的權(quán)限。

缺點(diǎn)：中央服務(wù)器的單點(diǎn)故障。

若是宕機(jī)一小時(shí)，那么在這一小時(shí)內(nèi)，誰(shuí)都無法提交更新、還原、對(duì)比等，也就無法協(xié)同工作。如果中央服務(wù)器的磁盤發(fā)生故障，并且沒做過備份或者備份得不夠及時(shí)的話，還會(huì)有丟失數(shù)據(jù)的風(fēng)險(xiǎn)。最壞的情況是徹底丟失整個(gè)項(xiàng)目的所有歷史更改記錄，被客戶端提取出來的某些快照數(shù)據(jù)除外，但這樣的話依然是個(gè)問題，你不能保證所有的數(shù)據(jù)都已經(jīng)有人提取出來。

Subversion原理上只關(guān)心文件內(nèi)容的具體差異。每次記錄有哪些文件作了更新，以及都更新了哪些行的什么內(nèi)容。

2.Git屬于分布式的版本控制系統(tǒng)

Git記錄版本歷史只關(guān)心文件數(shù)據(jù)的整體是否發(fā)生變化。Git 不保存文件內(nèi)容前后變化的差異數(shù)據(jù)。

實(shí)際上，Git 更像是把變化的文件作快照后，記錄在一個(gè)微型的文件系統(tǒng)中。每次提交更新時(shí)，它會(huì)縱覽一遍所有文件的指紋信息并對(duì)文件作一快照，然后保存一個(gè)指向這次快照的索引。為提高性能，若文件沒有變化，Git 不會(huì)再次保存，而只對(duì)上次保存的快照作一連接。

在分布式版本控制系統(tǒng)中，客戶端并不只提取最新版本的文件快照，而是把原始的代碼倉(cāng)庫(kù)完整地鏡像下來。這么一來，任何一處協(xié)同工作用的服務(wù)器發(fā)生故障，事后都可以用任何一個(gè)鏡像出來的本地倉(cāng)庫(kù)恢復(fù)。這類系統(tǒng)都可以指定和若干不同的遠(yuǎn)端代碼倉(cāng)庫(kù)進(jìn)行交互。籍此，你就可以在同一個(gè)項(xiàng)目中，分別和不同工作小組的人相互協(xié)作。你可以根據(jù)需要設(shè)定不同的協(xié)作流程。

另外，因?yàn)镚it在本地磁盤上就保存著所有有關(guān)當(dāng)前項(xiàng)目的歷史更新，并且Git中的絕大多數(shù)操作都只需要訪問本地文件和資源，不用連網(wǎng)，所以處理起來速度飛快。用SVN的話，沒有網(wǎng)絡(luò)或者斷開VPN你就無法做任何事情。但用Git的話，就算你在飛機(jī)或者火車上，都可以非常愉快地頻繁提交更新，等到了有網(wǎng)絡(luò)的時(shí)候再上傳到遠(yuǎn)程的鏡像倉(cāng)庫(kù)。換作其他版本控制系統(tǒng)，這么做幾乎不可能，抑或是非常麻煩。

Git具有以下特點(diǎn)：

Git中每個(gè)克隆(clone)的版本庫(kù)都是平等的。你可以從任何一個(gè)版本庫(kù)的克隆來創(chuàng)建屬于你自己的版本庫(kù)，同時(shí)你的版本庫(kù)也可以作為源提供給他人，只要你愿意。

Git的每一次提取操作，實(shí)際上都是一次對(duì)代碼倉(cāng)庫(kù)的完整備份。

提交完全在本地完成，無須別人給你授權(quán)，你的版本庫(kù)你作主，并且提交總是會(huì)成功。

甚至基于舊版本的改動(dòng)也可以成功提交，提交會(huì)基于舊的版本創(chuàng)建一個(gè)新的分支。

Git的提交不會(huì)被打斷，直到你的工作完全滿意了，PUSH給他人或者他人PULL你的版本庫(kù)，合并會(huì)發(fā)生在PULL和PUSH過程中，不能自動(dòng)解決的沖突會(huì)提示您手工完成。

沖突解決不再像是SVN一樣的提交競(jìng)賽，而是在需要的時(shí)候才進(jìn)行合并和沖突解決。

Git 也可以模擬集中式的工作模式

Git版本庫(kù)統(tǒng)一放在服務(wù)器中

可以為 Git 版本庫(kù)進(jìn)行授權(quán)：誰(shuí)能創(chuàng)建版本庫(kù)，誰(shuí)能向版本庫(kù)PUSH，誰(shuí)能夠讀?。寺。┌姹編?kù)

團(tuán)隊(duì)的成員先將服務(wù)器的版本庫(kù)克隆到本地；并經(jīng)常的從服務(wù)器的版本庫(kù)拉（PULL）最新的更新；

團(tuán)隊(duì)的成員將自己的改動(dòng)推（PUSH）到服務(wù)器的版本庫(kù)中，當(dāng)其他人和版本庫(kù)同步（PULL）時(shí)，會(huì)自動(dòng)獲取改變

Git 的集中式工作模式非常靈活

你完全可以在脫離Git服務(wù)器所在網(wǎng)絡(luò)的情況下，如移動(dòng)辦公／出差時(shí)，照常使用代碼庫(kù)

你只需要在能夠接入Git服務(wù)器所在網(wǎng)絡(luò)時(shí)，PULL和PUSH即可完成和服務(wù)器同步以及提交

Git提供 rebase 命令，可以讓你的改動(dòng)看起來是基于最新的代碼實(shí)現(xiàn)的改動(dòng)

Git 有更多的工作模式可以選擇，遠(yuǎn)非 Subversion可比

二、版本庫(kù)與工作區(qū)

Subversion的工作區(qū)和版本庫(kù)是截然分開的，而Git的工作區(qū)和版本庫(kù)是如影隨形的。

1.SVN的版本庫(kù)和工作區(qū)是分離的

Subversion 的工作區(qū)和版本庫(kù)物理上分開：Subversion的版本庫(kù)和工作區(qū)是存儲(chǔ)在不同路徑下，一般是在不同的主機(jī)中，Subversion的企業(yè)級(jí)部署中，版本庫(kù)在服務(wù)器上，只能通過 https, http, svn 等協(xié)議訪問，而不能直接被用戶接觸到。

Subversion的工作區(qū)是一份版本庫(kù)在某個(gè)歷史狀態(tài)下的快照，如：版本庫(kù)最新的數(shù)據(jù)檢出到工作區(qū)。

Subversion的工作區(qū)中每一個(gè)目錄下都包含一個(gè)名為 .svn 的控制目錄（隱藏的目錄），該目錄的作用是：

① 標(biāo)識(shí)工作區(qū)和版本庫(kù)的對(duì)應(yīng)關(guān)系。

② 包含一份該子目錄下檢出文件的原始拷貝。當(dāng)文件改動(dòng)的差異比較或者本地改動(dòng)的回退時(shí)，可以直接參考原始拷貝而無須通過網(wǎng)絡(luò)訪問遠(yuǎn)程版本庫(kù)。

Subversion 的 .svn 控制目錄會(huì)引入很多麻煩：

① .svn 下的文件原始考本，會(huì)導(dǎo)致在目錄下按照文件內(nèi)容搜索時(shí)，多出一倍的搜索時(shí)間和搜索結(jié)果。

② .svn 很容易在集成時(shí)，引入產(chǎn)品中，尤其是 Web 應(yīng)用，將 .svn 目錄帶入Web服務(wù)器會(huì)導(dǎo)致安全隱患。因?yàn)橐粋€(gè)不允許目錄瀏覽的Web目錄，可以通過 .svn/entries 文件查看到該目錄下可能存在的文件。

2 .Git 的版本庫(kù)和工作區(qū)如影隨形

Git 的版本庫(kù)和工作區(qū)在同一個(gè)目錄下，工作區(qū)的根目錄有一個(gè).git的子目錄，這個(gè)名為 .git的目錄就是版本庫(kù)本身，它是Git 用來保存元數(shù)據(jù)和對(duì)象數(shù)據(jù)庫(kù)的地方。該目錄非常重要，每次克隆鏡像倉(cāng)庫(kù)的時(shí)候，實(shí)際拷貝的就是這個(gè)目錄里面的數(shù)據(jù)。所以千萬要小心刪除這個(gè)文件。

工作區(qū)中其他文件為工作區(qū)文件，可能是從 .git 中檢出的，或者是要檢入的，或者是運(yùn)行產(chǎn)生的臨時(shí)文件等。

版本庫(kù)可以脫離工作區(qū)而存在，成為 bare（赤裸）版本庫(kù)。可以用 –bare參數(shù)來創(chuàng)建。但是工作區(qū)不能脫離版本庫(kù)而存在，即工作區(qū)的根目錄下必須有一個(gè)名為 .git 的版本庫(kù)克隆文件。

Git 的版本庫(kù)因?yàn)榫驮诠ぷ鲄^(qū)中，能直接被用戶接觸到。

① 用戶可以編輯 .git/config 文件，修改配置，增添新的源

② 用戶可以編輯 .git/info/exclude 文件，創(chuàng)建本地忽略…

Git 的工作區(qū)中只在工作區(qū)的根目錄下有一個(gè) .git 目錄，此外再無任何控制目錄。Git 工作區(qū)下唯一的 .git 目錄是版本庫(kù)，并非 .svn 的等價(jià)物，如果刪除了 .git 目錄，而又沒有該版本庫(kù)的其他鏡像（克?。┑脑?，你破壞了整個(gè)歷史，版本庫(kù)也永遠(yuǎn)的失去了。

Git 在本地的 .git 版本庫(kù)，提供了完全的改動(dòng)歷史。除了和其他人數(shù)據(jù)交換外，任何版本庫(kù)相關(guān)的操作都在本地完成，更多的本地操作，避免了冗長(zhǎng)的網(wǎng)絡(luò)延遲，大大節(jié)省了時(shí)間。例如：查看 log，切換到任何歷史版本等操作都無須連接網(wǎng)絡(luò)。

Git如何保證安全：本地創(chuàng)建一個(gè)Git庫(kù)，因?yàn)楣ぷ鲄^(qū)和庫(kù)是在同一個(gè)目錄中，如果工作區(qū)刪除了，或者所在的磁盤分區(qū)格式化了，數(shù)據(jù)不是全都沒有了么？其實(shí)我們可以這樣做：

① 在一個(gè)磁盤分區(qū)中創(chuàng)建版本庫(kù)（最好是用 –bare 參數(shù)創(chuàng)建），然后在另外的磁盤分區(qū)中克隆一個(gè)新的作為工作區(qū)。在工作區(qū)的提交要不時(shí)的PUSH到另外分區(qū)的版本庫(kù)，這樣就實(shí)現(xiàn)了本地的數(shù)據(jù)鏡像。你甚至可以在本地創(chuàng)建更多的版本庫(kù)鏡像，安全性要比Subversion的一個(gè)庫(kù)加上一個(gè)工作區(qū)安全。

② 另一個(gè)辦法：把你的版本庫(kù)共享給他人，當(dāng)他人克隆了你的版本庫(kù)時(shí)，你就擁有了一個(gè)異地備份。

三、全局版本號(hào)和全球版本號(hào)

SVN的全局版本號(hào)和CVS的每個(gè)文件都獨(dú)立維護(hù)一套版本號(hào)相比，是一個(gè)非常大的進(jìn)步。在看似簡(jiǎn)單的全局版本號(hào)的背后，是Subversion提供對(duì)于事物處理的支持，每一個(gè)事物處理（即一次提交）都具有整個(gè)版本庫(kù)全局唯一的版本號(hào)。

Git的版本號(hào)則更進(jìn)一步，版本號(hào)是全球唯一的。Git 對(duì)于每一次提交，通過對(duì)文件的內(nèi)容或目錄的結(jié)構(gòu)計(jì)算出一個(gè)SHA-1 哈希值，得到一個(gè)40位的十六進(jìn)制字符串，Git將此字符串作為版本號(hào)。

1. SVN與Git版本號(hào)比較

所有保存在Git 數(shù)據(jù)庫(kù)中的數(shù)據(jù)都是用此40位的哈希值作索引的，而不是靠文件名。

使用哈希值作版本號(hào)的好處就是對(duì)于一個(gè)分布式的版本控制系統(tǒng)，每個(gè)人每次提交后形成的版本號(hào)都不會(huì)出現(xiàn)重復(fù)。另一好處是保證數(shù)據(jù)的完整性，因?yàn)楣Ｖ凳歉鶕?jù)內(nèi)容或目錄結(jié)構(gòu)計(jì)算出來的，所以我們還可以據(jù)此來判斷數(shù)據(jù)內(nèi)容是否被篡改。

SVN 的版本號(hào)是連續(xù)的，可以預(yù)判下一個(gè)版本號(hào)，而 Git 的版本號(hào)則不是。

因?yàn)?subversion 是集中式版本控制，很容易實(shí)現(xiàn)版本號(hào)的連續(xù)性。Git 是分布式的版本控制系統(tǒng)，而且 Git 采用 40 位長(zhǎng)的哈希值作為版本號(hào)，每個(gè)人的提交都是各自獨(dú)立完成的，沒有先后之分（即使提交有先后之分，也由于PUSH/PULL的方向和時(shí)機(jī)而不同）。Git 的版本號(hào)雖然不連續(xù)，但是是有線索的，即每一個(gè)版本都有對(duì)應(yīng)的父版本（一個(gè)或者兩個(gè)），進(jìn)而可以形成一個(gè)復(fù)雜的提交鏈

Git 的版本號(hào)簡(jiǎn)化：Git 可以使用從左面開始任意長(zhǎng)度的字串作為簡(jiǎn)化版本號(hào)，只要該簡(jiǎn)化的版本號(hào)不產(chǎn)生歧義。一般采用7位的短版本號(hào)（只要不會(huì)出現(xiàn)重復(fù)的，你也可以使用更短的版本號(hào)）。

四、部分檢出

Subversion可以將整個(gè)庫(kù)檢出到工作區(qū)，也可以將某個(gè)目錄檢出到工作區(qū)。對(duì)于要使用一個(gè)龐大、臃腫的版本庫(kù)的用戶來說，部分檢出是非常方便和實(shí)際的。

但是Git只能全部檢出，不支持按照目錄進(jìn)行的部分檢出。

1. SVN的部分檢出

在SVN中，從倉(cāng)庫(kù)checkout的一個(gè)工作樹，每個(gè)子目錄下都維護(hù)著自己的.svn目錄，記錄著該目錄中文件的修改情況以及和服務(wù)器端倉(cāng)庫(kù)的對(duì)應(yīng)關(guān)系。所以SVN可以checkout部分路徑下的內(nèi)容（部分檢出），而不用checkout整個(gè)版本庫(kù)或分支。

Subversion 有一條命令：svn export ，可以將 subversion 版本庫(kù)的一個(gè)目錄下所有內(nèi)容導(dǎo)出到指定的目錄下。Subversion 需要 svn export 命令是因?yàn)樵撁羁梢詫?dǎo)出一個(gè)干凈的目錄，即不包含 .svn 目錄（包含配置文件和文件原始拷貝）。

2. Git的檢出

Git 沒有部分檢出，這并不是說只有將整個(gè)庫(kù)克隆下來才能查看文件。有很多 git 工具，提供直接瀏覽git庫(kù)的功能，例如 gitweb, trac 的 git 版本庫(kù)瀏覽, redmine 的 git 版本庫(kù)瀏覽。

Git-submodule 可以實(shí)現(xiàn)版本庫(kù)的模塊化：Git 通過子模塊處理這個(gè)問題。

子模塊允許你將一個(gè)Git 倉(cāng)庫(kù)當(dāng)作另外一個(gè)Git倉(cāng)庫(kù)的子目錄。這允許你克隆另外一個(gè)倉(cāng)庫(kù)到你的項(xiàng)目中并且保持你的提交相對(duì)獨(dú)立。

Git 為什么沒有實(shí)現(xiàn) svn export 的功能？由于git的本地倉(cāng)庫(kù)信息完全維護(hù)在project根目錄的.git目錄下，（不像svn一樣，每個(gè)子目錄下都有單獨(dú)的.svn目錄）。所以，只要clone，checkout然后刪除.git目錄就可以了。

五、更新和提交

1．更新操作

在SVN中，因?yàn)橹挥幸粋€(gè)中心倉(cāng)庫(kù)，所以所謂的遠(yuǎn)程更新，也就是svn update ,通過此命令來使工作區(qū)和版本庫(kù)保持同步。

對(duì)于git來說，別人的改動(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來完成遠(yuǎn)程更新任務(wù)，fetch操作只是將遠(yuǎn)程數(shù)據(jù)庫(kù)的object拷貝到本地，然后更新remotes head的refs，git pull 的操作則是在git fetch的基礎(chǔ)上對(duì)當(dāng)前分支外加merge操作。

2．SVN中的commit命令

對(duì)于SVN來說，由于是中心式的倉(cāng)庫(kù)管理形式，所以并不存在特殊的遠(yuǎn)程提交的概念，所有的commit操作都可以認(rèn)為是對(duì)遠(yuǎn)程倉(cāng)庫(kù)的更新動(dòng)作。在工作區(qū)中對(duì)文件進(jìn)行添加、修改、刪除操作要同步到版本庫(kù)，必須使用 commit命令。

add 命令，是將未標(biāo)記為版本控制狀態(tài)的文件標(biāo)記為添加狀態(tài)，并在下次提交時(shí)入庫(kù)。

delete命令，是通過SVN來刪除文件，并在下次提交后有效。

Subversion 有提交列表功能，即將某些文件加入一個(gè)修改列表，提交可以只提交處于該列表的文件。

3．Git中的暫存區(qū)域（stage）

Git 管理項(xiàng)目時(shí)，文件在三個(gè)工作區(qū)域中流轉(zhuǎn)：Git 的本地?cái)?shù)據(jù)目錄，工作目錄以及暫存區(qū)域。暫存區(qū)域（stage）是介于 workcopy 和 版本庫(kù)HEAD 版本的一種中間狀態(tài)。所謂的暫存區(qū)域只不過是個(gè)簡(jiǎn)單的文件，一般都放在git 目錄中。有時(shí)候人們會(huì)把這個(gè)文件叫做索引文件，不過標(biāo)準(zhǔn)說法還是叫暫存區(qū)域。

要將一個(gè)文件納入版本管理的范疇，首先是要用gitadd將文件納入stage的監(jiān)控范圍，只有更新到stage中的內(nèi)容才會(huì)在commit的時(shí)候被提交。另外，文件本身的改動(dòng)并不會(huì)自動(dòng)更新到stage中，每次的任何修改都必須重新更新到stage中去才會(huì)被提交。對(duì)于工作區(qū)直接刪除的文件，需要用 git rm 命令進(jìn)行標(biāo)記，在下次提交時(shí)，在版本庫(kù)中刪除。

工作區(qū)的文件改動(dòng)（新增文件，修改文件，刪除文件），必須用 git add 或者 git rm 命令標(biāo)識(shí)，使得改動(dòng)進(jìn)入 stage

提交只對(duì)加入 stage 的改動(dòng)進(jìn)行提交

如果一個(gè)文件改動(dòng)加入 stage 后再次改動(dòng)，則后續(xù)改動(dòng)不改變 stage。即該文件的改動(dòng)有兩個(gè)狀態(tài)，一個(gè)是標(biāo)記到 stage 中并將在下次提交時(shí)入庫(kù)的改動(dòng)，另外的后續(xù)改動(dòng)則不被提交，除非再次使用 git add 命令將改動(dòng)加入到 stage 中。

Git的stag讓你在提交的時(shí)候清楚的知道git將要提交哪些改動(dòng)。除非提交的時(shí)候使用 -a 參數(shù)（不建議使用）。

我們可以從文件所處的位置來判斷其狀態(tài)：如果是git目錄中保存著的特定版本文件，就屬于已提交狀態(tài)；如果作了修改并已放入暫存區(qū)域，就屬于已暫存狀態(tài)；如果自上次取出后，作了修改但還沒有放到暫存區(qū)域，就是已修改狀態(tài)，如果取出后未進(jìn)行修改則是未修改狀態(tài)。

在git中，因?yàn)橛斜镜貍}(cāng)庫(kù)和remote倉(cāng)庫(kù)之分，所以也就區(qū)別于commit 操作，存在額外的push命令，用于將本地倉(cāng)庫(kù)的數(shù)據(jù)更新到遠(yuǎn)程倉(cāng)庫(kù)中去。git push 可以選擇需要提交的、更新的分支以及制定該分支在遠(yuǎn)程倉(cāng)庫(kù)上的名字。

六、分支和里程碑的實(shí)現(xiàn)

幾乎每一種版本控制系統(tǒng)都以某種形式支持分支。使用分支意味著你可以從開發(fā)主線上分離開來，然后在不影響主線的同時(shí)繼續(xù)工作。在很多版本控制系統(tǒng)中，這是個(gè)昂貴的過程，常常需要?jiǎng)?chuàng)建一個(gè)源代碼目錄的完整副本，對(duì)大型項(xiàng)目來說會(huì)花費(fèi)很長(zhǎng)時(shí)間。

輕量級(jí)分支/里程碑的含義是，創(chuàng)建分支/里程碑的復(fù)雜度是o(1)，不會(huì)因?yàn)榘姹編?kù)的愈加龐大而變得緩慢。在CVS中，創(chuàng)建分支的復(fù)雜度是o(n)的，導(dǎo)致大的版本庫(kù)的的分支創(chuàng)建非常緩慢。

1．Subversion的分支/里程碑

Subversion輕量級(jí)分支和里程碑的實(shí)現(xiàn)是通過svn cp命令，即帶歷史的拷貝就是創(chuàng)建快速創(chuàng)建分支和里程碑的秘籍。Subversion的版本庫(kù)有特殊的設(shè)計(jì)，當(dāng)你復(fù)制一個(gè)目錄，你不需要擔(dān)心版本庫(kù)會(huì)變得十分巨大—Subversion并不是拷貝所有的數(shù)據(jù)，相反，它只是建立了一個(gè)已存在目錄樹的入口。這種“廉價(jià)的拷貝”就是創(chuàng)建分支/里程碑是輕量級(jí)的原因。

由于Svn的分支和標(biāo)簽是來自目錄拷貝，約定俗成是拷貝在 branches/和tags/目錄下。所謂分支，tag等概念都只是倉(cāng)庫(kù)中不同路徑上的一個(gè)對(duì)象或索引而已，和普通的路徑并沒有什么本質(zhì)的區(qū)別，誰(shuí)也不能阻止在一個(gè)提交中同時(shí)修改不同分支中的數(shù)據(jù)。

里程碑是對(duì)某個(gè)歷史提交所起的一個(gè)別名，作為歷史的標(biāo)記，是不應(yīng)該被更改的。svn的里程碑要建立到 tags/目錄下，要求不要在tags/下的里程碑目錄下進(jìn)行提交。但是誰(shuí)也阻止不了對(duì)未進(jìn)行權(quán)限控制的里程碑的篡改。

2．Git 的輕量級(jí)分支和里程碑

Git中的分支實(shí)際上僅是一個(gè)包含所指對(duì)象校驗(yàn)和（40個(gè)字符長(zhǎng)度SHA-1 哈希值）的文件，所以創(chuàng)建和銷毀一個(gè)分支就變得非常廉價(jià)。說白了，新建一個(gè)分支就是向一個(gè)文件寫入41個(gè)字節(jié)（版本號(hào)外加一個(gè)換行符）那么簡(jiǎn)單，自然速度就很快了。 Git的實(shí)現(xiàn)與項(xiàng)目復(fù)雜度無關(guān)，它永遠(yuǎn)可以在幾毫秒的時(shí)間內(nèi)完成分支的創(chuàng)建和切換。這和大多數(shù)版本控制系統(tǒng)形成了鮮明對(duì)比。

Git的分支是完全隔離的，而Subversion則沒有。分支本來就應(yīng)該是相對(duì)獨(dú)立的命名空間，一個(gè)提交一般只能發(fā)生在一個(gè)分支中。在Git中，其內(nèi)部的對(duì)象層級(jí)依賴關(guān)系或許和SVN類似，但是其工作樹的視圖表現(xiàn)形式和SVN完全不同。工作樹永遠(yuǎn)是一個(gè)完整的分支，不同的分支由不同的head索引去構(gòu)建，你不可能在工作樹中同時(shí)獲得多個(gè)分支的內(nèi)容。

Git使用的標(biāo)簽有兩種類型：輕量級(jí)的（lightweight）和含附注的（annotated）。① 輕量級(jí)標(biāo)簽就像是個(gè)不會(huì)變化的分支，實(shí)際上它就是個(gè)指向特定提交對(duì)象的引用。② 而含附注標(biāo)簽，實(shí)際上是存儲(chǔ)在倉(cāng)庫(kù)中的一個(gè)獨(dú)立對(duì)象，它有自身的校驗(yàn)和信息，包含著標(biāo)簽的名字，電子郵件地址和日期，以及標(biāo)簽說明，標(biāo)簽本身也允許使用GNU Privacy Guard (GPG) 來簽署或驗(yàn)證。

Git的里程碑是只讀的，Git完全遵守歷史不可更改這一時(shí)空法則。用戶不能向git的里程碑中提交，否則里程碑就不是標(biāo)記，而成了一個(gè)分支。當(dāng)然Git允許用戶刪除里程碑再重新創(chuàng)建指定到不同歷史提交。

3．多分支間的切換

SVN中提供了一個(gè)功能switch，使用switch可以在同一個(gè)工作樹上，在不同的分支中進(jìn)行切換。

Git在分支中進(jìn)行切換使用的命令是checkout。

七、分支與合并

Git 和 Svn 的分支實(shí)現(xiàn)機(jī)制完全的不同，這也直接導(dǎo)致了 SVN 在分支合并中困難重重。盡管在 SVN 1.5 之后，通過 svn:mergeinfo 屬性引入了合并追蹤機(jī)制，但是在特定情況下，合并仍會(huì)出現(xiàn)很多困難。

1．SVN的分支合并

當(dāng)你在一個(gè)分支上工作數(shù)周或幾個(gè)月之后，主干的修改也同時(shí)在進(jìn)行著，兩條線的開發(fā)會(huì)區(qū)別巨大，當(dāng)你想合并分支回主干，可能因?yàn)樘鄾_突，已經(jīng)無法輕易合并你的分支和主干的修改。

另一個(gè)問題，Subversion不會(huì)記錄任何合并操作，當(dāng)你提交本地修改，版本庫(kù)并不能判斷出你是通過svn merge還是手工修改得到這些文件。所以你必須手工記錄這些信息（說明合并的特定版本號(hào)或是版本號(hào)的范圍）。

要解決以上的問題只有通過有規(guī)律的將主干合并到分支來避免，制定這樣一個(gè)政策：每周將上周的修改合并到分支，注意這樣做時(shí)需要小心，你必須手工記錄合并的過程，以避免重復(fù)的合并，你需要小心的撰寫合并的日志信息，精確的描述合并包括的范圍。這樣做看起來有點(diǎn)像是脅迫。

SVN 的版本號(hào)是連續(xù)的版本號(hào)。每一次新的提交都會(huì)版本號(hào)+1 ，而無論這個(gè)提交是在哪個(gè)分支中進(jìn)行的。SVN一個(gè)提交可以同時(shí)修改不同分支的不同文件，因?yàn)樘峤幻羁梢栽?/trunk, /branches, /tags 的上一級(jí)目錄執(zhí)行。

SVN 的提交是單線索的，每一個(gè)提交（最原始的提交0除外）都只有一個(gè)父節(jié)點(diǎn)（版本號(hào)小一個(gè)的提交節(jié)點(diǎn)）

SVN 的提交鏈只有一條，僅從版本號(hào)和提交說明，我們無法獲得分支圖

SVN 的分支圖在某些工具（如烏龜SVN）可以提供，那是需要對(duì)提交內(nèi)容進(jìn)行檢查，對(duì)目錄拷貝動(dòng)作視為分支，對(duì) svn:mergeinfo 的改動(dòng)視為合并，但這會(huì)由于目錄管理的靈活性，導(dǎo)致千奇百怪的分支圖表。

2．Git的分支合并

在 git 版本庫(kù)中創(chuàng)建分支的成本幾乎為零，所以，不必吝嗇多創(chuàng)建幾個(gè)分支。當(dāng)?shù)谝淮螆?zhí)行g(shù)it-init時(shí)，系統(tǒng)就會(huì)創(chuàng)建一個(gè)名為”master”的分支。 而其它分支則通過手工創(chuàng)建。下面列舉一些常見的分支策略。

① 創(chuàng)建一個(gè)屬于自己的個(gè)人工作分支，以避免對(duì)主分支 master 造成太多的干擾，也方便與他人交流協(xié)作。

② 當(dāng)進(jìn)行高風(fēng)險(xiǎn)的工作時(shí)，創(chuàng)建一個(gè)試驗(yàn)性的分支，扔掉一個(gè)爛攤子總比收拾一個(gè)爛攤子好得多。

③ 合并別人修改的時(shí)候，最好創(chuàng)建一個(gè)臨時(shí)的分支用來合并，合并完成后再“fatch”到自己的分支。

Git分支相關(guān)的操作命令

八、撤消操作

1．提交的撤銷

在Subversion中一旦完成向服務(wù)器的數(shù)據(jù)提交，你就沒有辦法再?gòu)目蛻舳俗坊兀荒茉诤罄m(xù)的提交中修正（回退或者修改）等。因?yàn)镾ubversion作為集中式的版本控制，不能允許個(gè)人對(duì)已提交的數(shù)據(jù)進(jìn)行篡改。Subversion具有一個(gè)非常重要的特性就是它的信息從不丟失，即使當(dāng)你刪除了文件或目錄，它也許從最新版本中消失了 ，但這個(gè)對(duì)象依然存在于歷史的早期版本中。

Git則不同，Git是分布式版本控制系統(tǒng)，代碼庫(kù)是屬于個(gè)人，允許任意修改。Git通過對(duì)提交建立數(shù)字摘要來保證提交的唯一性和不可更改性，通過版本庫(kù)在多人之間的多份拷貝來保障數(shù)據(jù)的安全性。Git可以丟棄最新的一個(gè)或幾個(gè)提交，使用 git reset –hard命令可以永遠(yuǎn)丟棄最新的一個(gè)或者幾個(gè)提交。

2．提交說明的修改

提交后如果對(duì)提交說明不滿意，如何實(shí)現(xiàn)對(duì)提交說明的修改：

⑴ Git可以使用命令git commit –amend修改提交說明。

Git可以修改最后一次提交說明，并不是說不能修改歷史版本的提交說明，只是修改最后一個(gè)版本提交說明擁有最簡(jiǎn)單的命令；

Git修改提交說明，會(huì)改變提交的commit-id。即修改提交說明后，將產(chǎn)生一個(gè)新的提交；

Git可以通過git reset -hard ，git commit –amend，git rebase onto 等命令來實(shí)現(xiàn)對(duì)歷史提交的修改；

使用stg工具可以更為簡(jiǎn)單的修改歷史提交的提交說明，包括提交內(nèi)容；

⑵ Subversion也可以修改提交說明，是通過修改提交的svn:log版本屬性實(shí)現(xiàn)的：

不但可以修改最后一次提交的說明，并且可以修改歷史提交的提交說明；

Subversion修改提交說明是不可逆的操作，可能會(huì)造成說明被惡意修改；

Subversion缺省關(guān)閉修改提交說明的功能。管理員在設(shè)置了提交說明更改的郵件通知后，才可以打開該功能。

3．修改和重構(gòu)歷史提交

Git可以修改和重構(gòu)歷史提交：使用Git本身的reset以及 rebase 命令可以修改或者重整/重構(gòu)歷史提交，非常靈活。使用強(qiáng)大的 stg 可以使得歷史提交的重構(gòu)更為簡(jiǎn)潔，如果您對(duì) stg 或者 Hg/MQ 熟悉的話。

Subversion 修改歷史提交，只能由管理員完成。

Subversion 是集中式版本控制系統(tǒng)，從客戶端一旦完成提交，就沒有辦法從客戶端撤銷提交。但是管理員可以在服務(wù)器端完成提交的撤銷和修改，但是操作過程和代價(jià)較大。

九、權(quán)限管理

Subversion通過對(duì)文件目錄授權(quán)來實(shí)現(xiàn)權(quán)限管理，子目錄默認(rèn)繼承父目錄的權(quán)限。但是也有缺憾，即權(quán)限不能在分支中繼承，不能對(duì)單個(gè)文件授權(quán)。例如為 /trunk及其子目錄的授權(quán)，不能繼承到分支或者標(biāo)簽中相應(yīng)的目錄下。

Git 的授權(quán)做不到Subversion那樣精細(xì)。Git的授權(quán)模型只能實(shí)現(xiàn)非零即壹式的授權(quán)，要么擁有全部的寫權(quán)限，要么沒有寫權(quán)限，要么擁有整個(gè)版本庫(kù)的讀權(quán)限，要么禁用。

從技術(shù)上將，Git可能永遠(yuǎn)也做不到類似SVN的路徑授權(quán)（讀授權(quán)）：

如果允許按照路徑授權(quán)，則各個(gè)克隆的關(guān)系將不再是平等的關(guān)系，有的內(nèi)容多，有的內(nèi)容少，分布式的理念被破壞

如果只有部分路徑可讀，則克隆出來的提交和原始提交的提交ID可能不同。因?yàn)樘峤籌D是和提交內(nèi)容有關(guān)的，克隆中提交的部分內(nèi)容被丟棄，勢(shì)必提交的ID也要重新計(jì)算

允許全部代碼可讀，只允許部分代碼可寫，在版本控制的管理下，是沒有多大實(shí)際意義的，而且導(dǎo)致了提交的邏輯上的不完整。

那么有什么辦法來解決授權(quán)的問題？

1.公司內(nèi)部代碼開放。即代碼在公司內(nèi)部，對(duì)項(xiàng)目組成員一視同仁的開放。

2.公司對(duì)代碼庫(kù)進(jìn)行合理分解，對(duì)每個(gè)代碼庫(kù)分別授權(quán)。即某個(gè)代碼庫(kù)對(duì)團(tuán)隊(duì)成員完全開放，對(duì)其它團(tuán)隊(duì)完全封閉。

3.公司使用Subversion做集中式的版本控制，個(gè)人和/或團(tuán)隊(duì)使用 Git-svn。這樣在無法改變公司版本控制策略時(shí)，程序員可以采用的變通之法。

4.Git服務(wù)器的部署實(shí)際上可以使用鉤子對(duì)分支和路徑進(jìn)行寫授權(quán)，即可以控制誰(shuí)能夠創(chuàng)建分支，能夠?qū)懱囟ㄎ募?/p>

十、優(yōu)缺點(diǎn)比較

1．SVN優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

1、 管理方便，邏輯明確，符合一般人思維習(xí)慣。

2、 易于管理，集中式服務(wù)器更能保證安全性。

3、 代碼一致性非常高。

4、 適合開發(fā)人數(shù)不多的項(xiàng)目開發(fā)。

缺點(diǎn)：

1、 服務(wù)器壓力太大，數(shù)據(jù)庫(kù)容量暴增。

2、 如果不能連接到服務(wù)器上，基本上不可以工作，看上面第二步，如果服務(wù)器不能連接上，就不能提交，還原，對(duì)比等等。

3、 不適合開源開發(fā)（開發(fā)人數(shù)非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明確的權(quán)限管理機(jī)制（例如分支訪問限制），可以實(shí)現(xiàn)分層管理，從而很好的解決開發(fā)人數(shù)眾多的問題。

2．Git優(yōu)缺點(diǎn)優(yōu)點(diǎn)：

1、適合分布式開發(fā)，強(qiáng)調(diào)個(gè)體。

2、公共服務(wù)器壓力和數(shù)據(jù)量都不會(huì)太大。

3、速度快、靈活。

4、任意兩個(gè)開發(fā)者之間可以很容易的解決沖突。

5、離線工作。

缺點(diǎn)：

1、學(xué)習(xí)周期相對(duì)而言比較長(zhǎng)。

2、不符合常規(guī)思維。

3、代碼保密性差，一旦開發(fā)者把整個(gè)庫(kù)克隆下來就可以完全公開所有代碼和版本信息。

以上就是SVN與Git版本控制的優(yōu)缺點(diǎn)差異全面分析的詳細(xì)內(nèi)容，更多關(guān)于SVN與Gi版本控制差異分析的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論