1、什么是版本控制系統(tǒng)

版本控制是一種記錄一個(gè)或若干個(gè)文件內(nèi)容變化，以便將來(lái)查閱特定版本修訂情況的系統(tǒng)。版本控制系統(tǒng)不僅可以應(yīng)用于軟件源代碼的文本文件，而且可以對(duì)任何類型的文件進(jìn)行版本控制。

有了它你就可以將某個(gè)文件回溯到之前的狀態(tài)，甚至將整個(gè)項(xiàng)目都回退到過(guò)去某個(gè)時(shí)間點(diǎn)的狀態(tài)，你可以比較不同版本文件的變化細(xì)節(jié)，查出最后是誰(shuí)修改了哪個(gè)地方。也就是無(wú)論文件最后被修改成什么樣子，你都可以輕松恢復(fù)到原先的樣子，但是額外增加的工作量卻微乎其微。

2、我們?yōu)槭裁匆冒姹究刂?/h2>

世界上無(wú)數(shù)大大小小的開發(fā)項(xiàng)目，都在使用各種各樣的版本控制系統(tǒng)，原因在于它的優(yōu)點(diǎn)對(duì)于一個(gè)項(xiàng)目開發(fā)來(lái)說(shuō)是無(wú)比重要。

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

如果這個(gè)團(tuán)隊(duì)采用了版本控制，那么版本控制軟件在每次提交文件的時(shí)候，都會(huì)主動(dòng)合并所有人的修改，并解決可能發(fā)生的沖突。每個(gè)人手里一直都是匯總好的代碼，當(dāng)開發(fā)進(jìn)行到一定階段，可以直接拿去測(cè)試，不需要再有額外的工作來(lái)浪費(fèi)時(shí)間。

3、版本管理系統(tǒng)的演變

（1）本地版本控制系統(tǒng)

許多人習(xí)慣用復(fù)制整個(gè)項(xiàng)目目錄的方式來(lái)保存不同的版本，或許還會(huì)改名加上備份時(shí)間以示區(qū)別。 這么做唯一的好處就是簡(jiǎn)單，但是特別容易犯錯(cuò)。 有時(shí)候會(huì)混淆所在的工作目錄，一不小心會(huì)寫錯(cuò)文件或者覆蓋意想外的文件。

為了解決這個(gè)問(wèn)題，人們很久以前就開發(fā)了許多種本地版本控制系統(tǒng)，大多都是采用某種簡(jiǎn)單的數(shù)據(jù)庫(kù)來(lái)記錄文件的歷次更新差異。

這種形式主要實(shí)現(xiàn)了基本的代碼版本管理，但缺點(diǎn)是無(wú)法讓多人同時(shí)對(duì)一個(gè)版本庫(kù)進(jìn)行修改。這個(gè)也和當(dāng)時(shí)軟件規(guī)模不夠大有關(guān)，也沒有這樣的需求。

（2）集中化版本控制系統(tǒng)

接下來(lái)人們又遇到一個(gè)問(wèn)題，如何讓在不同系統(tǒng)上的開發(fā)者協(xié)同工作？ 于是，集中化的版本控制系統(tǒng)（Centralized Version Control Systems，簡(jiǎn)稱 CVCS）應(yīng)運(yùn)而生。 這類系統(tǒng)，諸如 CVS、Subversion等，都有一個(gè)單一的集中管理的服務(wù)器，保存所有文件的修訂版本，而協(xié)同工作的人們都通過(guò)客戶端連到這臺(tái)服務(wù)器，取出最新的文件或者提交更新。 多年以來(lái)，這已成為版本控制系統(tǒng)的標(biāo)準(zhǔn)做法。

這種做法帶來(lái)了許多好處，特別是相較于老式的本地 VCS 來(lái)說(shuō)。 現(xiàn)在，每個(gè)人都可以在一定程度上看到項(xiàng)目中的其他人正在做些什么。 而管理員也可以輕松掌控每個(gè)開發(fā)者的權(quán)限，并且管理一個(gè) CVCS 要遠(yuǎn)比在各個(gè)客戶端上維護(hù)本地?cái)?shù)據(jù)庫(kù)來(lái)得輕松容易。

事分兩面，有好有壞，集中管理的服務(wù)器最顯而易見的缺點(diǎn)是中央服務(wù)器的單點(diǎn)故障問(wèn)題。 如果宕機(jī)一小時(shí)，那么在這一小時(shí)內(nèi)，誰(shuí)都無(wú)法提交更新，也就無(wú)法協(xié)同工作。 如果中心數(shù)據(jù)庫(kù)所在的磁盤發(fā)生損壞，又沒有做恰當(dāng)備份，毫無(wú)疑問(wèn)你將丟失所有數(shù)據(jù)，包括項(xiàng)目的整個(gè)變更歷史，只剩下人們?cè)诟髯詸C(jī)器上保留的單獨(dú)快照。 本地版本控制系統(tǒng)也存在類似問(wèn)題，只要整個(gè)項(xiàng)目的歷史記錄被保存在單一位置，就有丟失所有歷史更新記錄的風(fēng)險(xiǎn)。

集中式版本控制系統(tǒng)另外一個(gè)大的問(wèn)題就是必須聯(lián)網(wǎng)才能工作，如果不能連接到中央服務(wù)器上，就不能對(duì)文件進(jìn)行提交，還原，對(duì)比等操作。

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

于是分布式版本控制系統(tǒng)（Distributed Version Control System，簡(jiǎn)稱 DVCS）面世了。 在這類系統(tǒng)中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客戶端并不只提取最新版本的文件快照，而是把代碼倉(cāng)庫(kù)完整地鏡像下來(lái)。 這么一來(lái)，任何一處協(xié)同工作用的服務(wù)器發(fā)生故障，事后都可以用任何一個(gè)鏡像，把本地倉(cāng)庫(kù)恢復(fù)。 因?yàn)槊恳淮蔚目寺〔僮?，?shí)際上都是一次對(duì)代碼倉(cāng)庫(kù)的完整備份。

許多這類系統(tǒng)都可以指定和若干不同的遠(yuǎn)端代碼倉(cāng)庫(kù)進(jìn)行交互。因此你就可以在同一個(gè)項(xiàng)目中，分別和不同工作小組的人相互協(xié)作。 你可以根據(jù)需要設(shè)定不同的協(xié)作流程，比如層次模型式的工作流，而這在以前的集中式系統(tǒng)中是無(wú)法實(shí)現(xiàn)的。

參考：

http://www.fzitv.net/article/245601.htm

以上就是git基礎(chǔ)之各版本控制系統(tǒng)介紹的詳細(xì)內(nèi)容，更多關(guān)于git版本控制系統(tǒng)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論