软件发布都会涉及到版本管理问题，这里涉及到对外发布的产品版本，也有内部代码管理的代码版本。这里对两个内容分别进行讨论。
产品版本
对外发布后，在前端展示，用户可见的产品版本号。可以采用三段式命名规则。如下：
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，一般是线上问题修复，使用后删除
随时随地看视频
