版本控制已經出現有些年頭了。然而，我還是會被人問起一些，諸如版本控制是什麼或者它是如何工作的，這樣基礎的問題。本文會概括地解釋版本控制解決的重要問題，本文使用的場景針對的是原始碼版本控制。
目前有很多不同型別的版本控制系統（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 編譯：伯樂線上 – 唐尤華
【如需轉載，請標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】