版本控制已經(jīng)出現(xiàn)有些年頭了。然而，我還是會被人問起一些，諸如版本控制是什么或者它是如何工作的，這樣基礎(chǔ)的問題。本文會概括地解釋版本控制解決的重要問題，本文使用的場景針對的是源代碼版本控制。

目前有很多不同類型的版本控制系統(tǒng)（Version Control System， VCS）。一些VCS，比如Subversion和CVS，以中央倉庫（repository）為中心進(jìn)行架構(gòu)。此外，還有分布式的VCS（Distributed VCS，DVCS）， Git 和 Mercurial 是兩個(gè)新近出現(xiàn)的DVCS。然而，在上述兩種類型的環(huán)境中，通常會有一個(gè)“指定的”中央倉庫。對應(yīng)地，比如一個(gè)Subversion服務(wù)器或者一個(gè)GitHub倉庫。下面會基于這個(gè)場景進(jìn)行圖示說明。那么讓我們開始吧。

在開發(fā)者拷貝到本機(jī)之前，服務(wù)器需要?jiǎng)?chuàng)建一個(gè)倉庫。創(chuàng)建初始倉庫會由于產(chǎn)品不同而有所差別。從現(xiàn)在起，你所要知道的就是，在服務(wù)器上有一個(gè)初始空間。我把這個(gè)版本稱作版本“A”。

現(xiàn)在，每個(gè)開發(fā)者（開發(fā)者1和開發(fā)者2）都會拷貝版本“A”到他們本地電腦。再一次地，從服務(wù)器拷貝的過程會由于產(chǎn)品不同采用的技術(shù)會有所差別。

每個(gè)開發(fā)者會在他們的本地拷貝上進(jìn)行開發(fā)。他們的本地拷貝基于版本“A”。然而，由于他們應(yīng)該不會做同樣的開發(fā)，因而他們的版本會有所差別。因此，會有2個(gè)以上的版本會同時(shí)被創(chuàng)建，比如版本“B”和版本“C”。


開發(fā)者1首先完成了她的工作并提交到服務(wù)器。服務(wù)器上的當(dāng)前版本被更新成版本“B”。


開發(fā)者2現(xiàn)在完成了他的工作并試圖提交到服務(wù)器。然而，這是服務(wù)器告知他基于開發(fā)的版本已經(jīng)發(fā)生改變。這也是為什么采取版本控制的首要原因之一。這個(gè)特性是對網(wǎng)絡(luò)共享代碼然后由開發(fā)者手動更新的一個(gè)跨越式發(fā)展，這確保了之前的編輯沒有被新的修改覆蓋。


開發(fā)者2必須首先獲得所有版本“B”的變化，并合并到他的修改中，然后才可以提交到服務(wù)器。這個(gè)過程聽起來有些復(fù)雜。然而，大多數(shù)現(xiàn)代的版本控制系統(tǒng)十分高級，能夠自動在開發(fā)者的本地拷貝上完成合并。有幾種情況會產(chǎn)生沖突（例如：開發(fā)者1和開發(fā)者2同時(shí)修改了同一個(gè)文件的同一行）。這就是一些VCS產(chǎn)品比其他更高級的地方。不論如何完成合并，現(xiàn)在開發(fā)者2在他們的本地系統(tǒng)上同時(shí)混合了版本B和版本C。


現(xiàn)在開發(fā)者2可以提交他的版本到服務(wù)器。

這是一個(gè)版本控制的基礎(chǔ)。通過注意觀察圖中服務(wù)器的連線可以發(fā)現(xiàn)版本控制的原理。服務(wù)器記錄了所有先前的版本包括發(fā)生的變化，什么時(shí)候發(fā)生以及由誰進(jìn)行修改。當(dāng)需要進(jìn)行代碼回溯或者引入其他bug時(shí)，這個(gè)記錄能夠解除困境。
我希望本文能夠?yàn)榘姹究刂葡到y(tǒng)提供一個(gè)基礎(chǔ)的介紹。如果你有任何疑問，請就你問題發(fā)表評論。
 
英文原文：greenmoonsoftware 編譯：伯樂在線 – 唐尤華