分支管理

现状

• 分支管理：

  1. 分支混乱，且发布分支太过随意，功能 B 分支未拉取已发布的功能 A 分支代码， 导致线上的分支 A 的功能丢失。
  2. 未建立合理 PR 流程，导致功能分支越来越多。
  3. 未有合理的 Tag，导致在代码层面没有版本概念。

• 环境

  1. dev
  2. test
  3. pro

方案

• master分支

1. 主分支，用于部署生产环境的分支，是所有分支的主干，与当前线上代码保持统一
2. 由主开发人员、研发组 leader 管控
3. 不允许开发者在该分支上直接开发

• dev分支：

1. 开发分支，开发各类功能的合并分支，即当前最新功能的分支
2. 不允许开发者在该分支上直接开发
3. test 环境指定分支

• feature分支

1. 功能分支，一般为 开发独立功能/新技术研究尝试 时创建，以 feature-xxx 命名(xxx 表示功能的简单描述)
2. 从master分支上面分出来的
3. 开发过程中，dev环境可基于功能分支部署，但若需要test环境测试，则合并代码到 dev 分支上。
4. 开发完成之后，提交 pr，合并到master分支。
5. 基于 master 创建tag，并发布到生产环境

• fixbug分支

1. bug修复分支，修复完成之后，合并到master& dev 分支上，并删除该分支
2. 常规bug，以 bugfix_xxx 命名。xxx 表示 bug 的简单描述。
3. 紧急bug， 以 hotfix_xxx 命名。xxx 表示 bug 的简单描述

tag 标签

1. tag 用来标记版本，在 master 分支上的每个 tag 都对应历史的一个线上版本
2. tag 命名：
   v 主版本号.子版本号.阶段版本号.日期版本号_软件阶段
   v1.0.0.051021_beta
   v1.0.0.061021_release
3. 基于 tag 创建 GitHub Release， 用来记录发布版本的详细信息

实施步骤

• jenkins 需要添加 groovy 脚本，对环境-分支映射关系进行限制。