浅谈版本管理-Git分支管理

        软件发布都会涉及到版本管理问题，这里涉及到对外发布的产品版本，也有内部代码管理的代码版本。这里对两个内容分别进行讨论。

    产品版本

    对外发布后，在前端展示，用户可见的产品版本号。可以采用三段式命名规则。如下：

    x.y.z [-stage]

• x、y、z都是自然数

• x代表大版本号，业务发生重要更新内容，或者代码的重要重构，或者ui的全面提升等等，一般由高层领导决定，开发周期较长。如果x为0，一般表示版本还在内部迭代开发阶段，未对外正式发布。

• y一般表示的是迭代功能，产品人员决定

• z一般是小的版本更新，缺陷修复，功能完善，可以由开发人员确定

• stage一般不常用，如果带上RC标识，表示是候选版本，一般是对特定客户交付时采用；带上Preview一般表示为预览版本，非正式提供服务。

  
  

    实例：

    正式版 v1.2.1
候选版 v3.1.3-RC
预览版 v5.1.11-Preview

代码版本

开发人员对代码的管理，通常使用svn、git等版本管理工具。这里讨论的是git管理。版本管理中是标签（tag）进行标识，识别具体的代码版本。

一般命令：

git tag v2.2.1
git tag -a v3.1.11 -m "对tag标签进行说明，也就版本的注释，如新增了什么功能"

分支管理，使用不同的分支（branch）区分环境：

• master，主分支，收到分支保护，只接受合并请求。

• dev，开发分支，一般为默认分支，开发人员提交合并，可部署到开发环境，开发人员在此环境调试代码

• test，此分支代码部署到测试环境，供测试人员进行功能验证

• pro，生产环境，收保护，不能直接提交合并，一般通过审核后才可以进行合并操作，合并之前代码需要测试通过。此分支对应线上代码。

• further，需求功能，单独功能开发，使用后删除

• hotfix，一般是线上问题修复，使用后删除