如果說什麼是軟件開發項目一定要使用的基礎工具，那麼版本控制系統應該算最重要的部分。不管是個人開發或是團隊協作開發，都可以通過版本控制系統獲得巨大的好處。
沒有版本控制系統的話，代碼可能被別人或自己不小心覆蓋或遺失、也不知道是誰因爲什麼原因改了這段代碼、也沒辦法可以復原回前幾天的修改。有了版本控制系統，開發人員只要將每次程式碼的變更都紀錄（Commit）起來，並且透過版本控制系統中進行更新。
有了版本控制系統，我們可以瀏覽所有開發的歷史紀錄，掌握團隊的開發進度，而且作任何修改都不再害怕，因爲你可以輕易的復原回之前正常的版本。我們也可以透過分支和標籤的功能來進行軟件發行的不同版本，例如穩定版本、維護版本和開發中版本。
很多項目需求方還沒有明白開發的定義，這裏必須要跟大家說一點老生常談的段子：“開發永遠是個過程，而不是結果。”所以開發者一定要使用版本控制系統，Git或Mercurial是免費開源的版本系統系統、隨處可用的網絡、便宜的雲端服務器，甚至有現成的第三方服務Github。
如果你還沒有使用的話，建議馬上爲你的軟件開發項目建立版本控制。接下來是幾點使用版本控制系統的建議：
1.將所有東西都放進版本控制系統
是的，所有項目開發過程中的產出物都放到版本控制系統之中，這包括了程序源代碼、測試程序、文件、設定檔、各種自動化腳本等等。除了新成員可以很容易拉出最新的版本馬上開始工作之外，我們也希望在測試環境、正式環境中，也可以隨時更新到我們所指定的版本，因此將所有變更的紀錄保存起來是非常重要的。
例如，數據庫的變更也必須納入版本控制。首先，在數據庫中紀錄它目前的版本編號。接着我們每次的修改都透過一個自動化腳本來執行，並將這個腳本放入版本控制之中，而不是手動用指令去修改綱要。這樣的好處是團隊中每個人都可以透過版本控制系統看到這個變更，並且升級他的數據庫。測試和正式的服務器環境，也會透過這個腳本來自動進行升級。筆者熟悉的Ruby on Rails中就有內置這樣的Migration機制，其他程序語言也有類似的數據庫工具。
另外，以服務器應用來說，光是有源代碼還是無法100%讓軟件工作起來，我們還需要知道服務器的配置設定，包括基礎網絡設定、操作系統設定、依賴的套件版本等等。因此最好這些配置設定也可以納入版本管理系統之中。近年來雲端技術的進步，已經可以將這些基礎設施設定當作程序，無縫地讓每個成員和所有環境都使用完全相同的設定，減少出錯的可能性。
2.頻繁且適當大小的遞交
如果久久才遞交一次修改到版本控制系統，那麼你只是把版本控制系統當作一種備份工具而已，而沒有享受到它真正的好處。頻繁的遞交可以幫助團隊開發進度的透明化，減少多人開發時的代碼衝突。當多人同時修改同一塊代碼時，解決代碼衝突是很麻煩的事情。還有，我們也希望每一次的遞交有適當的粒度大小，也就是每個提交的內容應該有高度相關性和獨立性。例如是一個小功能或是一個小改進。如果你同時在做新功能A和修舊Bug，那麼就應該分開兩次遞交。語法錯誤無法建構的程序也不應該提交從而造成團隊困擾。
有良好大小的代碼提交習慣的好處除了版本的歷史紀錄更加清楚之外，我們可以非常輕易的做代碼的復原或移植，假設上述的新功能A有問題，我們可以只復原A而不影響修好的Bug，或是隻挑選修Bug的移植到不同分支去。
3.良好的遞交信息
每一次的遞交程序員都必須附上一段解釋信息，說明修改的內容和原因。這除了可以幫助團隊合作之外，更重要的是讓軟件有更好的維護性，以便將來備查，以下的場景相信開發者都不陌生：
軟件發現一個Bug，然後指派給你修復。
你追代碼追到一段看不懂的程序，也沒有任何註釋。
透過版本控制系統，你找到了同事在一年前加了這行，遞交的信息是BUG或簡單的錯誤提示。
同事還在公司，可是他也不記得當初是哪一個BUG了。或是他已經下班或離職了，反正找不到。
你強行改了這行代碼，發佈出去。
這個功能是修好了，但是發現另一個功能又出現問題。
繼續加班到凌晨，悲催ing....
一個好的遞交信息應該包括一行摘要信息，描述你爲什麼做這段變更，可能是新增、移除、修正某個功能，而不是描述新增或修改哪些檔案，重點應放在備註爲什麼修改而不是這段是bug這麼簡單。因爲修改了哪些檔案和行數我們看版本差異就知道了，無須重複描述。如果你發現很難摘要，那可能表示你包含太多變更在同一次遞交了，請試着拆開。