# 前端版本管理

# git 上的分支命名规范

  • master:主分支,永远是可用的、稳定的、可直接发布的版本,不能直接在该分支上开发
  • develop:开发主分支,代码永远是最新,所有新功能以这个分支来创建自己的开发分支,该分支只做只合并操作,不能直接在该分支上开发
  • feature-xxx:功能开发分支,在 develop 上创建分支,以自己开发功能模块命名,功能测试正常后合并到 develop 分支
  • release:预分布分支,在合并好 feature 分支的 develop 分支上创建,主要是用来测试 bug 的分支,修改好 bug 并确定稳定之后合并到 develop 和 master 分支,然后发布 master 分支
  • release-fix:功能 bug 修复分支,在 release 上创建分支修复,修复好测试出来的 bug 之后合并回 release 分支
  • hotfix-xxx:紧急 bug 修改分支,项目上线之后可以会遇到一些环境问题需要紧急修复,在 master 分支上创建,流程跟 release 分支相似,修复完成后合并到 develop 和 master 分支

# 软件发布版本命名规范

# 1. 软件版本阶段说明

  • Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主,通常只在软件开发者内部交流,一般而言,该版本软件的 Bug 较多,需要继续修改。
  • Beta版: 该版本相对于 α 版已有了很大的改进,消除了严重的错误,但还是存在着一些缺陷,需要经过多次测试来进一步消除,此版本主要的修改对像是软件的 UI。
  • RC版: 该版本已经相当成熟了,基本上不存在导致错误的 BUG,与即将发行的正式版相差无几。
  • Release版: 该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式版本,是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下,Release 不会以单词形式出现在软件封面上,取而代之的是符号(R)。

# 2. 版本命名规范

软件版本号由四部分组成:

  • 第一个 1 为主版本号
  • 第二个 1 为子版本号
  • 第三个 1 为阶段版本号
  • 第四部分为日期版本号加希腊字母版本号

希腊字母版本号共有 5 种,分别为:basealphabetaRCrelease。例如:1.1.1.051021_beta

常规:完全的版本号定义,分三项::<主版本号>.<次版本号>.<修订版本号>,如 1.0.0

# 3. 版本号定修改规则

  • 主版本号(1):当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
  • 子版本号(1):当功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
  • 阶段版本号(1):一般是 Bug 修复或是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的 bug 即可发布一个修订版。此版本号由项目经理决定是否修改。
  • 日期版本号(051021): 用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
  • 希腊字母版本号(beta): 此版本号用于标注当前版本的软件处于哪个开发阶段,当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

# 4. 文件命名规范

文件名称由四部分组成:第一部分为项目名称,第二部分为文件的描述,第三部分为当前软件的版本号,第四部分为文件阶段标识加文件后缀,例如:项目外 包平台测试报告 1.1.1.051021_beta_b.xls,此文件为项目外包平台的测试报告文档,版本号为:1.1.1.051021_beta

如果是同一版本同一阶段的文件修改过两次以上,则在阶段标识后面加以数字标识,每次修改数字加 1,项目外包平台测试报告 1.1.1.051021_beta_b1.xls

当有多人同时提交同一份文件时,可以在阶段标识的后面加入人名或缩写来区别,例如:项目外包平台测试报告 1.1.1.051021_beta_b_LiuQi.xls。当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别,例如:项目外包平台测试 报告 1.1.1.051021_beta_b_LiuQi2.xls

# Changelog

github-changelog-generator:https://github.com/github-changelog-generator/github-changelog-generator

github-changelogs:https://github.com/lalitkapoor/github-changes