前端版本管理

前面的話

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

 

概述

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

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

　　二、查看歷史版本

　　三、對比兩個版本差別

分類

　　通常地，有四種版本控制系統。包括手動版本控制(又叫人肉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爲例)】

優勢：

　　一、 管理方便，邏輯明確，符合通常人思惟習慣

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

　　三、 代碼一致性很是高

缺點：

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

　　二、 單點故障問題。若是中心服務器出現故障，全部操做都沒法進行

　　三、 操做依賴網絡。若是不能鏈接到代碼服務器上，就不能提交，還原，對比等等，基本上不能夠工做

　　四、 不適合開源開發(開發人數很是很是多)

【DVCS(git爲例)】

優勢：

　　一、 快速、靈活。每一個開發中本地都有全量倉庫，提交到本地很是快

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

　　三、 任意兩個開發者之間能夠很容易的合併和解決衝突

缺點：

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

　　二、 代碼保密性差，不便於權限控制。一旦開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息，權限控制須要另一套系統來保證

　　所以，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)的代碼

 

最後

　　本文是蔡劍飛、鄭海波老師的《產品前端架構》課程中《版本管理》章節的學習記錄