逛奔的蝸牛

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

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

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

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

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


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


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


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


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

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