分支管理

默认分支配置入口：

平台默认会根据 GitFlow 在项目设置中生成对应分支规则配置，可以按需修改

分支规则配置入口：

平台建议代码分支（branch & tag）的命名遵循 GitFlow 命名规范。该规范由 Vincent Driessen at nvie 提出并广泛使用。分支名称分为，develop，feature branches，release branches，，support branches 六种类型。平台会对新建的项目应用设置符合GitFlow的默认规则，不符合规范的分支，在平台上无法进行打包部署等相关操作。

核心分支

master
develop

develop 分支

develop 分支记录完整的研发过程，是开发人员平时主要交互的分支。

master 分支

master 分支的 HEAD 代表着应用当前的”生产”分支，并关联了所有上线过的历史版本。

支撑分支

使用四类分支进行研发过程支撑：

feature 分支
release 分支
hotfix 分支
support 分支

feature 分支用于开发新特性，必需满足：

从 develop 分支开辟出来
最终合并到 develop 分支
命名必需以 feature/ 为前缀

一般一个迭代周期中会并行存在多个 feature 分支，由多名研发人员独立开发实现功能需求。当完成各个 feature 的开发后，研发人员协同好将各个 feature 分支一起合并到 develop 分支进行冒烟测试。

release 分支

release 分支用于新版本发布。测试人员基于 develop 分支完成功能测试后，开辟 release 分支进行预发环境发布。release 分支必需满足：

从 develop 分支开辟出来
最终合并到 master 和 develop 分支
命名必需以 release/ 为前缀，一般后接版本号

hotfix 分支

hotfix 分支用于紧急修复线上 bug。线上发现紧急 bug 后由开发人员基于 master 分支开辟 hotfix 分支进行快速修复。hotfix 分支必需满足：

从 master 分支（或者 support 分支）开辟出来
最终合并到 master 和 develop 分支，（或者 support 分支）
命名必需以为前缀，一般后接版本号

support 分支

support 分支用于历史版本的支持。一般情况下 master 分支会持续迭代，但有些系统会停留在某个版本不再做频繁迭代。那就需要基于 master 分支上的某次 release tag 开辟出一个 support 分支进行单独维护。support 分支必需满足：

命名必需以 support/ 为前缀，一般后接版本号

分支与环境

主要在流水线新建页面中会有所体现：

项目管理员创建应用仓库；
创建 master 分支；
基于 master 分支开辟 develop 分支。

开发迭代

开发工程师基于 develop 分支开辟 feature/A、feature/B 等等，发布 development 环境进行自测；
开发工程师合并所有 feature 分支到 develop 分支，发布 test 环境冒烟测试；
如果测试有 bug，迭代上面两步，直到冒烟测试通过，然后提交测试。

测试集成

测试工程师人员基于开发工程师提测的 develop 分支在 test 环境进行集成测试；
开发工程师从 develop 分支开辟 feature 分支修复测试工程师发现的 bug，自测后合并入 develop 分支公测试工程师继续测试；
迭代上面两步直到集成测试通过，然后开辟 release 分支提交发布。

预发验证

测试工程师将 release 分支部署 staging 环境进行回归验证；
开发工程师在 release 分支修复测试工程师发现的 bug，直到回归测试通过；
开发工程师将 release 分支上的修复合并回 develop 分支，同时将 release 分支合并 master 分支。

生产上线

运维工程师将 master 分支发布到 production 环境，测试工程师线上环境进行功能验证；
开发工程师基于 master 分支开辟 hotfix 分支修复测试工程师发现的 bug；
测试工程师将 hotfix 分支部署 staging 环境进行 bugfix 验证，直到验证通过；
开发将 hotfix 分支合并 master 和 develop 分支；

release、master 分支合并操作权限只有应用管理员才有，其他分支合入全部需要线上走合并请求流程。

合并请求入口：