目前有很多不同類型的版本控制系統（Version Control System， VCS）。一些VCS，比如Subversion和CVS，以中央倉庫（repository）為中心進行架構。此外，還有分布式的VCS（Distributed VCS，DVCS）， Git 和 Mercurial 是兩個新近出現的DVCS。然而，在上述兩種類型的環境中，通常會有一個“指定的”中央倉庫。對應地，比如一個Subversion服務器或者一個GitHub倉庫。下面會基于這個場景進行圖示說明。那么讓我們開始吧。在開發者拷貝到本機之前，服務器需要創建一個倉庫。創建初始倉庫會由于產品不同而有所差別。從現在起，你所要知道的就是，在服務器上有一個初始空間。我把這個版本稱作版本“A”。現在，每個開發者（開發者1和開發者2）都會拷貝版本“A”到他們本地電腦。再一次地，從服務器拷貝的過程會由于產品不同采用的技術會有所差別。每個開發者會在他們的本地拷貝上進行開發。他們的本地拷貝基于版本“A”。然而，由于他們應該不會做同樣的開發，因而他們的版本會有所差別。因此，會有2個以上的版本會同時被創建，比如版本“B”和版本“C”。開發者1首先完成了她的工作并提交到服務器。服務器上的當前版本被更新成版本“B”。開發者2現在完成了他的工作并試圖提交到服務器。然而，這是服務器告知他基于開發的版本已經發生改變。這也是為什么采取版本控制的首要原因之一。這個特性是對網絡共享代碼然后由開發者手動更新的一個跨越式發展，這確保了之前的編輯沒有被新的修改覆蓋。開發者2必須首先獲得所有版本“B”的變化，并合并到他的修改中，然后才可以提交到服務器。這個過程聽起來有些復雜。然而，大多數現代的版本控制系統十分高級，能夠自動在開發者的本地拷貝上完成合并。有幾種情況會產生沖突（例如：開發者1和開發者2同時修改了同一個文件的同一行）。這就是一些VCS產品比其他更高級的地方。不論如何完成合并，現在開發者2在他們的本地系統上同時混合了版本B和版本C。現在開發者2可以提交他的版本到服務器。這是一個版本控制的基礎。通過注意觀察圖中服務器的連線可以發現版本控制的原理。服務器記錄了所有先前的版本包括發生的變化，什么時候發生以及由誰進行修改。當需要進行代碼回溯或者引入其他bug時，這個記錄能夠解除困境。我希望本文能夠為版本控制系統提供一個基礎的介紹。如果你有任何疑問，請就你問題發表評論。 英文原文：greenmoonsoftware
400 186 1886
