前端版本管理

前面的话

　　版本管理在产品级开发中是很是重要的一个部分，它涉及到团队协做，且影响到产品最终的发布、上线以及测试环节。本文将详细介绍版本管理

 

概述

　　版本控制系统(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)的代码

 

最后

　　本文是蔡剑飞、郑海波老师的《产品前端架构》课程中《版本管理》章节的学习记录