作者：13
GitHub：https://github.com/ZHENFENG13
版權宣告：本文為原創文章，未經允許不得轉載。
前言
還好在第一篇文章裡就列好了接下來的主線及要寫的知識點，不然都不知道要寫什麼東西了，開篇裡已經列了基礎篇要講svn和git的知識點，所以這一篇就寫一下版本控制。
專案展示地址，點這裡http://ssm-demo.13blog.site，賬號：admin 密碼：123456
當然，也可以直接匯入原始碼， 點選這裡下載程式碼。
Github地址在這裡：https://github.com/ZHENFENG13
版本控制的定義
維基百科的解釋：
版本控制（Revision control）是維護工程藍圖的標準作法，能追蹤工程藍圖從誕生一直到定案的過程。此外，版本控制也是一種軟體工程技巧，藉此能在軟體開發的過程中，確保由不同人所編輯的同一程式檔案都得到同步。
由這個概念中我們得出兩個版本控制的關鍵點，一個是記錄，一個是同步。
為什麼要用版本控制？
沒有版本控制系統的話，程式碼可能被別人或自己不小心覆蓋或遺失、也不知道是誰因為什麼原因改了這段程式碼、也沒辦法可以復原回前幾天的修改。有了版本控制系統，開發人員只要將每次開發的變更都紀錄（Commit）起來，並且透過版本控制系統中進行更新。
每個人都在修改、新增、刪除著自己本地硬碟上的程式碼，當他們把這些程式碼彙總起來時，麻煩出現了，總不能每次都去copy程式碼然後把檔案傳給其他人。還有，到底誰改了哪些檔案，具體是檔案裡的哪部分被改動過？一個人的修改會不會把另外一個人的修改給覆蓋掉？上線前，程式碼彙總的工作變得非常危險，需要非常小心，一旦出錯後果不堪設想，而且這種情況下，大家的工作不僅僅是開發，無形中，給所有人增加了很多工作量，效率將會變低，如果某個地方出錯，可能程式碼彙總的工作又要重來一遍。這只是兩三人的小團隊，如果是幾十人幾百人的大團隊呢？那將會是噩夢，當然，幾百人的團隊也不可能出現這種情況，我們只是做一個假設。
如果這個團隊採用了版本控制。我們可以瀏覽所有開發的歷史紀錄，而且作任何修改都不再害怕，因為你可以輕易的復原回之前正常的版本，版本控制工具也會在每次提交的時候主動合併所有人的修改並解決可能發生的衝突，每個人手裡一直都是彙總好的程式碼。當開發進行到一定階段，可以直接拿去測試，不需要再有額外的工作來浪費時間。另外，你還可以知道，程式的某個Bug是怎麼出現的，是被哪位同事，在哪個時間點造成的，最重要的一點是，不怎麼需要刻意去去可以問一下開發人員進行到哪一步，通過版本控制，掌握團隊的開發進度，對整個開發流程有很大的幫助。版本控制工具中也有很多其他功能，我們也可以透過分支和標籤的功能來進行軟體發行的不同版本，例如穩定版、維護版和開發中版。
你不是一個人
上一段落講了一下為什麼要用版本控制，只是講一下版控的好處及積極影響，其實最重要的一點就是，我們開發人員要有一個意識，就是“你不是一個人”，你是團隊中的一員，以往寫的文章中也提過很多次，時間也是重要的資源，需要合理協調和分配，我們要保證開發質量和開發效率，在團隊中普及一些提升工作效率的工具是非常重要的。
git和svn
版本控制的工具還是很多的，例如文章開頭所提到的svn和git應該是較為流行的兩個版本控制工具，目前文章中提到的demo原始碼都是託管於github上，方便大家去查閱和學習，我的部落格中偶爾也會寫一些版本控制相關的文章。有人也對於兩個工具做了一個簡單的總結：“svn 好學不好用，git 好用不好學”。當然，別人所說的總結都只是代表別人，不能代表你的觀點，工具的好壞以及適合與否只有你親身體驗過才會知道。
關於兩者的區別，可以參考如下兩篇文章，http://www.jianshu.com/p/bfec042349ca，http://www.cnblogs.com/somethingWithiOS/p/5636356.html，區別還是很多的，但是最終的目的只有一個，提高我們的開發效率，減少時間成本。
還有比如“那個誰誰誰用了git了”“git比svn要好”等等諸如此類的觀點，所以“我們也要用git”，針對於此，我想說的是，我們是為了解決問題，而不是為了技術而技術，要根據自身情況出發，適合自己的才是最好的。
這兩個工具都很優秀，具體選哪個，自行決定，關於svn伺服器的搭建，網上教程很多，git的話也有一些國內的替代倉庫，或者你也可以用gitlab自己搭建一個私有倉庫，如果有時間的話，會介紹一下兩個工具搭建的詳細步驟，你現在也可以搜尋一下，相關教程也是很多的。
結語
還是要重點提一下，版本控制工具在專案的持續整合和持續部署中扮演著重要的角色，這個知識點會在以後的篇幅中展開論述(這裡先佔個坑)。本篇關於版本控制的文章到此也就告一段落了，主要講述了一下定義及版控的好處，最後提了一下幾種具體的實施方案，選擇哪一種就看各自的需求了，至於最終的方案落地就自己動手實踐吧。
如果還沒開始用版本控制的抓緊時間用起來吧。