分支规范Git分支使用规范

目录

一、对比《Git分支使用规范V2》完善内容

简化分支命名规范

完善版本命名说明

二、分支介绍

固定分支

临时分支

三、分支使用流程及规则

初始化固定分支

---

一、对比《Git分支使用规范V2》完善内容

流程思路基本相同，简化分支命名规范，完善Tag命名说明。

简化分支命名规范

固定分支不再带项目名，PLM_DEV——>develop、PLM_QA——>qa、PLM_RELEASE——>master、PLM_TRAIN——>train
临时分支不再带日期，feature_20201111_oa——>feature_oa

完善版本命名说明

正式环境发布分支Tag
所有在正式环境发布分支(master分支)被合并时必须打Tag号，记录版本，以便于上线更新失败时回滚。Tag命名规则:Vx.y.z_发布日日期，例如：V1.0.1_20201111,x.y.z的具体说明见下一节产品/代码版本标识及升级原则
测试环境分支Tag
所有测试环境分支被合并时必须打Tag号，记录版本，是测试部门人员测试时的版本依据。Tag命名规则：qa_此次测试功能标识_更新日期，例如：qa_oa_20201111

附：产品/代码版本标识：

采用[x].[y].[z]的三位格式，[x]、[y]、[z]均为数字
初始版本为1.0.0

附：产品/代码版本升级原则：

[x]:重大功能变更(比如增加多个模块)/整体架构变更的情况下增加1；编号原则上小于10
[y]:新需求/迭代开发/新功能/中等规模功能变更的情况下增加1，编号原则上小于100
[z]:修改BUG/小功能的变更/其他小的变更情况下增加1，编号原则上小于100

二、分支介绍

分支分为固定分支和临时分支，其中固定分支用于组织与软件开发、部署相关的活动；临时分支为了解决特定的问题而进行的各种开发活动，这些分支总是有有限的生命时间，因为它们最终将被合并到固定分支后移除。

固定分支

develop：主开发分支，各个子开发分支（包括feature和hotfix分支）最后都要合并到该分支，确保该分支上的代码最新。
qa：测试环境分支，即测试环境更新使用的代码，从feature上进行合并。
master：正式环境分支，即线上环境更新使用的代码，从develop上合并。
train：培训环境分支，即培训环境更新使用的代码，原则上也是从develop上合并，实际操作过程中可以按需求进行合并。

临时分支

feature_*：新功能开发分支，当开始一个新特征的开发时，基于develop创建feature分支。feature分支的本质是，只要特性处于开发/测试阶段，它就会存在，将来会被合并回develop分支（为了即将测试的版本而明确地添加新特性），或者丢弃掉（如果是令人失望的实验），合并或者决定废弃后建议删除。
hotfix_*：线上BUG修复分支，当线上出现一个严重的bug，需要立即修复的时候，就需要从master分支上指定的tag版本创建hotfix分支，来进行紧急修复工作（这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作）。完成hotfix后，合并回master和develop分支，合并后该分支建议删除。

三、分支使用流程及规则

随着项目的开发、测试、上线过程，逐步创建固定分支以及临时分支。其中train分支特殊说明一下，有培训需求的时候将develop并到train以便更新培训环境进行培训，在日常开发测试过程中不涉及其更新，可以理解成不是必要分支，以下不进行说明。

初始化固定分支

项目开始时，创建固定分支develop、qa、master，所有在master分支上被合并一次都需要打TAG号，记录版本，以便于上线更新失败时回滚。