互聯網產品開發：爲何版本控制如此重要？

　　若是說什麼是軟件開發項目必定要使用的基礎工具，那麼版本控制系統應該算最重要的部分。不論是我的開發或是團隊協做開發，均可以經過版本控制系統得到巨大的好處。

　　沒有版本控制系統的話，代碼可能被別人或本身不當心覆蓋或遺失、也不知道是誰由於什麼緣由改了這段代碼、也沒辦法能夠復原回前幾天的修改。有了版本控制系統，開發人員只要將每次程式碼的變動都紀錄（Commit）起來，而且透過版本控制系統中進行更新。

　　有了版本控制系統，咱們能夠瀏覽全部開發的歷史紀錄，掌握團隊的開發進度，並且做任何修改都再也不懼怕，由於你能夠輕易的復原回以前正常的版本。咱們也能夠透過度支和標籤的功能來進行軟件發行的不一樣版本，例如穩定版本、維護版本和開發中版本。

　　不少項目需求方尚未明白開發的定義，這裏必需要跟你們說一點老生常談的段子：「開發永遠是個過程，而不是結果。」因此開發者必定要使用版本控制系統，Git或Mercurial是免費開源的版本系統系統、隨處可用的網絡、便宜的雲端服務器，甚至有現成的第三方服務Github。

　　若是你尚未使用的話，建議立刻爲你的軟件開發項目創建版本控制。接下來是幾點使用版本控制系統的建議：

　　1.將全部東西都放進版本控制系統

　　是的，全部項目開發過程當中的產出物都放到版本控制系統之中，這包括了程序源代碼、測試程序、文件、設定檔、各類自動化腳本等等。除了新成員能夠很容易拉出最新的版本立刻開始工做以外，咱們也但願在測試環境、正式環境中，也能夠隨時更新到咱們所指定的版本，所以將全部變動的紀錄保存起來是很是重要的。

　　例如，數據庫的變動也必須歸入版本控制。首先，在數據庫中紀錄它目前的版本編號。接着咱們每次的修改都透過一個自動化腳原本執行，並將這個腳本放入版本控制之中，而不是手動用指令去修改綱要。這樣的好處是團隊中每一個人均可以透過版本控制系統看到這個變動，而且升級他的數據庫。測試和正式的服務器環境，也會透過這個腳原本自動進行升級。筆者熟悉的Ruby on Rails中就有內置這樣的Migration機制，其餘程序語言也有相似的數據庫工具。

　　另外，以服務器應用來講，光是有源代碼仍是沒法100%讓軟件工做起來，咱們還須要知道服務器的配置設定，包括基礎網絡設定、操做系統設定、依賴的套件版本等等。所以最好這些配置設定也能夠歸入版本管理系統之中。近年來雲端技術的進步，已經能夠將這些基礎設施設定看成程序，無縫地讓每一個成員和全部環境都使用徹底相同的設定，減小出錯的可能性。

　　2.頻繁且適當大小的遞交

　　若是久久才遞交一次修改到版本控制系統，那麼你只是把版本控制系統看成一種備份工具而已，而沒有享受到它真正的好處。頻繁的遞交能夠幫助團隊開發進度的透明化，減小多人開發時的代碼衝突。當多人同時修改同一塊代碼時，解決代碼衝突是很麻煩的事情。還有，咱們也但願每一次的遞交有適當的粒度大小，也就是每一個提交的內容應該有高度相關性和獨立性。例如是一個小功能或是一個小改進。若是你同時在作新功能A和修舊Bug，那麼就應該分開兩次遞交。語法錯誤沒法建構的程序也不該該提交從而形成團隊困擾。

　　有良好大小的代碼提交習慣的好處除了版本的歷史紀錄更加清楚以外，咱們能夠很是輕易的作代碼的復原或移植，假設上述的新功能A有問題，咱們能夠只復原A而不影響修好的Bug，或是隻挑選修Bug的移植到不一樣分支去。

　　3.良好的遞交信息

　　每一次的遞交程序員都必須附上一段解釋信息，說明修改的內容和緣由。這除了能夠幫助團隊合做以外，更重要的是讓軟件有更好的維護性，以便未來備查，如下的場景相信開發者都不陌生：

　　軟件發現一個Bug，而後指派給你修復。

　　你追代碼追到一段看不懂的程序，也沒有任何註釋。

　　透過版本控制系統，你找到了同事在一年前加了這行，遞交的信息是BUG或簡單的錯誤提示。

　　同事還在公司，但是他也不記得當初是哪個BUG了。或是他已經下班或離職了，反正找不到。

　　你強行改了這行代碼，發佈出去。

　　這個功能是修好了，可是發現另外一個功能又出現問題。

　　繼續加班到凌晨，悲催ing....

　　一個好的遞交信息應該包括一行摘要信息，描述你爲何作這段變動，多是新增、移除、修正某個功能，而不是描述新增或修改哪些檔案，重點應放在備註爲何修改而不是這段是bug這麼簡單。由於修改了哪些檔案和行數咱們看版本差別就知道了，無須重複描述。若是你發現很難摘要，那可能表示你包含太多變動在同一次遞交了，請試着拆開。