程式開發的過程中，總是會遇到一種問題：「我上次到底做了什麼？」。通常會有這個問題都是原本程式 compile 很正常，一修改完就出現錯誤。情況輕微是程式執行發生 Fatal Error，還能看得出在哪一行錯誤。情況嚴重就是 compile 過，可是執行結果是錯誤的。
這時就建議可以來學習 Version Control 了。
以下是目前有實作的 VCS：
原始碼托管服務
Without VCS
相信大型專案或是多人開發時，一定會出現下列問題：
- 「剛剛是改了什麼地方，怎麼突然不能執行？」
- 「嘿！某某！這檔案你有改過嗎？什麼！你也有改？是改哪裡？」
因為這些問題，所以出現了版本控制的需求。版本控制的主要目的在於記錄專案內程式碼的變動過程，以便未來做追縱或回朔。
Before Start
開始之前，先了解一個重要的問題：
真的有需要用到 VCS 嗎？
當然 VCS 的好用是用過的人才會知道，但是學習曲線太高，導致會有人不想花時間投資在學 VCS 上。其實最重要的一個關鍵點就是，當用 VCS 能大幅減少專案執行失誤的話，相信這是需要投資的時刻了。
一般而言，以下情況使用 VCS 都能有效的減少錯誤發生：
- 多人協同合作的專案
- 大型專案
所以相對的，如果只是單人的小專案，用 VCS 也許只是浪費時間而已。
History of File Management
從以前就有版本控制的方法了，這邊針對從以前到現在的檔案管理方法做一個簡單的說明
複本
完成一個版本時，把整個資料夾做完整備份，方法簡單，可是因為同樣的原始碼太多，造成維護困難。因為是完整備份，所以會多花出空間和備份的時間。
差異備份
新的版本只儲存與舊版本的差異，空間與備份時間能夠有效降低，如果需要還原時，需把每個版本的檔案依序解開，才能完成還原，反而造成不便。
中央式版本控制系統
版本控制的檔案庫全都在同一台伺服器上進行，稱之為中央式系統。
比起複本和差異備份的方法，除了可以有效管理原始碼，對於還原版本的方法也比較簡易。兩個以上的開發者想編輯相同的檔案，會使用 Lock 的方法，相對的就顯得沒有效率了。
分散式版本控制系統
版本控制的檔案庫在開發者端進行，稱之為分散式系統。
開發者不靠網路也能工作，且有充份的版本控制能力。分散式系統也允許讓兩個以上的開發者編輯同一個檔案，相對的也有 Lock 的功能。缺點是整個團隊都需要了解分散式系統的架構，且要遵守團隊定義使用方法。
History of Collaborative Work
以前應用程式功能的需求，可能一個人就能包辦所有的功能開發了；但現今程式架構越來越大，加上雲端網路和虛擬主機的興起，對於應用程式功能的需求也跟著變大。
要如何做多人協同開發變成開發部門的一個頭痛的問題。
開發部門除了基本的溝通和分配任務外，在程式開發的議題上，程式碼的更新和分享是個很大的問題。
以下就看這些問題到底是如何解決的：
Lock
當其中一個開發者開始編修一個檔案時，就把該檔案鎖住，而其他開發者就無法同時編輯該檔案。
聽起來好像很合理，可是關鍵的問題點在於，假設編輯時遇到的問題來源是在其他檔案上，而其他檔案剛好有人在修改時，這時就會完全動彈不得了。當然這個方法有它一個絕對的好處：簡單易懂好上手，因此至今仍然有許多公司都還採用這種方法當做多人協同開發的方式。
Merge
之後，版本控制系統出現了一個功能稱之為 合併。
開發者可以對同一個檔做更動，並提交更改到伺服器上，如果有衝突的話，都能互相去修復衝突，進而達到共同開發的效果。合併上會遇到的問題點就是解決衝突，通常會發生衝突的原因大都是兩個開發者改同一個檔案後要合併，如果彼此間不了解對方程式碼功能時，在解決衝突上也是會遇上許多問題。但是實際開發的效率大多都會比使用鎖檔來的高。
Pull Request
針對合併上的問題，在分散式版本控制系統裡用一個新的模式來解決： 拉取。
專案團隊裡會有一位主要維護者，可以接受其他開發者的拉取要求，將修改新增的項目拉取到自己的專案中，並做預覽；沒問題之後再做合併。這方法會把所有的負擔全都放在專案維護者上，整體效率也就只能取決於維護者的效率了。
Code Review
如果把專案維護者的負擔都分攤給每位開發者，讓大家一起預覽並討論程式是否可行，這樣除了整體效率能夠上升之外，每位開發者也能對於每一部分的程式碼都會有所了解。當然這個方法的缺點大概就是每位開發者必需要遵守團隊開發原則了。