前面的話

　　版本管理在產品級開發中是非常重要的一個部分，它涉及到團隊協作，且影響到產品最終的發布、上線以及測試環節。本文將詳細介紹版本管理

概述

　　版本控制系統(Version Control System)是一種記錄若幹文件修訂記錄的系統，它有以下三個作用：

　　1、從當前版本回退到任意版本

　　2、查看歷史版本

　　3、對比兩個版本差異

分類

　　一般地，有四種版本控制系統。包括手動版本控制(又叫人肉VCS)、LVCS 本地、CVCS 集中式(如SVN)和DVCS 分布式(如Git)

【人肉VCS】

　　使用人肉VCS無法有效找到需要版本，無法方便地查看各個版本之間的差異，可能需要兩個文件放在一起來對比。最大的問題是，汙染工作目錄結構，導致無法集合精力維護當前正在編輯的版本

【Local VCS(本地式)】

　　為了解決以上問題，出現了本地式的版本控制工具，比如RCS(Reversion Control System)，其利用本地版本數據庫存儲不斷出現的文件版本

　　這樣，它可以迅速找出需求的版本和維持工作目錄結構。但是，其缺點是不支持協同開發，這也讓開發者不將其選做通用的版本控制工具來使用

【Center VCS(集中式)】

　　集中式版本管理系統包括CVS(Cocurrent Versions System)、SVN(Subversion)、Perforce等，其中最有名的就是SVN

　　集中式版本管理系統利用中央服務器來進行日常的版本控制操作，比如checkout、commit等。所有的操作都必須經過中央服務器，優點是可控性更高，但每一次操作都需要網絡請求，會影響操作的流暢性，且具有致命的單點故障。一旦中央服務器發生了故障，輕則無法協同工作，重則可能會丟失歷史消息

【Distributed VCS(分布式)】

　　分布式版本管理系統包括Git、Mercurial等，其中最有名的是Git

　　分布式指的是每一份本地倉庫都是一個完整的項目歷史拷貝，即使同步的中央服務器發生了故障，也可以很容易地從本地倉庫中將歷史還原出來。帶來的好處是，如果部分操作不需要同步到服務器，可以在本地進行相關操作，這樣可以讓操作更加流暢

對比

　　由於Git的持續火熱，對於DVCS與CVCS的爭論和對比越來越多了，似乎很多文章都傾向於這個觀點：" Git這種DVCS要比SVN這些DVCS要優越"，實際情況真的是這樣嗎？

【CVCS(svn為例)】

優點：

　　1、 管理方便，邏輯明確，符合一般人思維習慣

　　2、 集中式服務器更能保證安全性，權限機制的設計也更加簡潔明確。一般集中式管理的有非常明確的權限管理機制(例如分支訪問限制)，可以實現分層管理

　　3、 代碼一致性非常高

缺點：

　　1、 中心代碼服務器壓力大，代碼數據庫容量暴增

　　2、 單點故障問題。如果中心服務器出現故障，所有操作都無法進行

　　3、 操作依賴網絡。如果不能連接到代碼服務器上，就不能提交，還原，對比等等，基本上不可以工作

　　4、 不適合開源開發(開發人數非常非常多)

【DVCS(git為例)】

優點：

　　1、 快速、靈活。每個開發中本地都有全量倉庫，提交到本地非常快

　　2、 離線工作，能避免單點故障。即便遠端代碼服務器崩潰，開發者也能繼續工作，無需等待修復。一定程度也是一種安全備份

　　3、 任意兩個開發者之間可以很容易的合並和解決沖突

缺點：

　　1、 學習曲線稍微陡峭一些，要多花一點學習時間

　　2、 代碼保密性差，不便於權限控制。一旦開發者把整個庫克隆下來就可以完全公開所有代碼和版本信息，權限控制需要另外一套系統來保證

　　因此，cvcs適合開發人數不多、對權限安全性要求更高的企業級項目；而dvcs適合團隊分布在天南海北，對靈活性要求更高的開源項目

分支模型

　　如果多人並行在一條線上開發會導致開發困難並且難以定位錯誤位置

　　於是，分支模型出現了

　　分支，就是從目標倉庫獲得一份項目拷貝，每條分支都具有和原倉庫功能一樣的開發線。可以在這個開發線提交代碼，也可以回退到某個版本

　　分支模型(Branching Model)或稱之為工作流(Workflow)，它是一個圍繞項目開發、部署、測試等工作流的分支操作(創建及合並等)的規範集合

　　在小型項目中，使用下圖所示的簡單的分支模型已經足夠

　　在產品級的開發中，簡單的分支模型不足以維護代碼，接下來介紹產品級的分支模型

　　產品級分支模型有兩類，包括常駐分支和活動分支。常駐分支一旦被創建就不會被更改；活動分支會隨著產品的發布而被動態地創建，有時完成開發時會將其刪除，只留下對應的版本號

【常駐分支】

　　開發分支(development)必須從master分支創建，而master分支就是所說的產品分支(production)

　　產品分支(master)上的代碼都必須是可發布的，產品分支(master)也是默認分支。開發分支(development)和產品分支(master)一旦生成就不會改變

【活動分支】

　　特性分支(feature)是從開發分支(development)進行創建的，它是開發人員平時會經常用到的分支

　　Bug修復分支(hotfix)從產品分支(master)創建，因為一般都是由於線上的Bug產生的，用於修復Bug

　　發布分支(release)從開發分支(development)創建，它標誌著一個產品開始正式發布

工作流

　　工作流包括特性開發和發布線兩部分

【特性開發】

　　首先從開發分支(development)創建兩個特性分支(feature)，這兩個特性分支(feature)並行開發，feature1開發完畢後，合並到開發分支(development)上。假如feature2依賴於feature1的提交，需要將feature1的提交合並到feature2。這其中可能會有沖突，需要解決沖突。feature2開發完畢後，合並到開發分支(development)上。所有特性開發完畢，準備合並到發布分支(release)

　　假設，同時在開發另外一個特性分支unrelease，但該特性不在下一個版本進行發布，那麽將完全不受到發布線的影響

【發布線】

　　當所有的特性分支(feature)都合並到開發分支(development)，準備發布，創建發布分支(release)，它會擁有當前開發分支(development)的所有信息

　　之後，進行一些產品的Bug修復，也會有一些源數據(如版本號、配置文件等)的更新，所有的這些在發布分支(release)提交的代碼都需要合並到開發分支(development)，這樣更好地在開發分支(development)進行版本的維護。因為，發布分支(release)是一個活動性分布，它可能會在發布結束之後被刪除

　　接下來，準備在發布分支(release)上發布1.0版本，然後將發布分支(release)提交的代碼合並到開發分支(development)。除此之外，還需要推送到產品分支(master)，並打上版本號(V1.0)。由於產品分支(master)的代碼可以直接上線，所以推送到產品分支(master)意味著該版本要上線了

　　但有時，開發並不理想，會在線上也就是產品分支(master)上發現一些Bug，這些Bug會通過小版本進行處理。比如在(v0.1)版本發現一個Bug，會創建一個Bug修復分支(hotfix)，完成Bug修復，將其合並到產品分支(master)，創建(v0.2)版本

　　這裏要註意的一點是代碼修復的提交也需要合並到開發分支(development)。這樣，在後續這個熱修復的分支被刪除之後也能定位到該提交

環境

　　開發環境使用測試/開發配置，包括數據庫、緩存、元數據配置等信息，使用的是需要提交到下一個發布分支(release)的特性分支(feature)的代碼，基本上會在本地測試特性分支(feature)

　　測試環境使用測試配置，包括測試數據庫、緩存等，使用的是發布分支(release)或開發分支(development)的代碼

　　預發布環境，相當於一個小範圍的發布，為了更好地模擬真實環境，使用線上數據庫。它使用的是發布分支(release)的代碼

　　生產環境使用線上配置，使用的是產品分支(master)的代碼

前端版本管理