需求开发管理流程及分支管理规范

1、需求开发管理流程

2、分支管理规范

目的：

1.定义分支的用途，使代码分支及版本结构清晰，方便维护

2.避免错误版本发布或上线的版本被新版本覆盖

前提：

每个需求在开发流程里统一定义好，写在标题前面

主要采用AoneFlow,不熟悉的同学可以先看下

开发分支管理模型之阿里AoneFlow_darkerxi的博客-CSDN博客_aoneflow分支模型

分支命名规范：

<dev>_<大版本号>.<功能版本号>.<发布版本号>_<负责人>_<需求编码>_<备用号，可选>_<时间版本号yyMMdd,可选>

时间版本号：添加分支时的年月日，记录版本timeline。也可以清楚当前版本之后建的分支，以及该版本之前是否还有未上master的分支

大版本号：增加大的主业务功能或者代码重构等版本号加1

功能版本号：每次做新需求时，该版本号加1

发布版本号：默认从0开始，需求上线后出现bug等情况，新建分支时该版本号加1

需求编码：跟开发流程里的需求号对应，多个服务对应一个需求，都是同一个需求号。尽量不要太长，但也尽量描述清楚职责

备用号：如果觉得需求号不够描述或上线后出现bug需要修复等情况用于辅助或增强描述分支的用途

<大版本号>.<功能版本号>.<发布版本号>对应到pom里的版本号

示例：

dev_1.2.5_hery_qtNew （针对需求编码为qtNew的分支）

dev_1.2.50_hery_qtNew_fix  （qtNew上线后发现问题，新开该需求的修复分支qtNew）

dev_1.2.6_hery_sdNew（针对需求编码为sdNew的分支）

....

dev_1.2.9_hery_sdNew（针对需求编码为sdNew的分支）

dev_1.3.0_hery_sdNew（注意进位）

...

dev_1.9.9_hery_sdNew（针对需求编码为sdNew的分支）

dev_1.10.0_hery_sdNew（注意进位）

dev_2.0.0_hery_newbegin_161214（大版本分支）

注意事项

1.【严格执行】仅通过release分支上线

2.【严格执行】release分支上线后及时将release合并至master分支,保持master分支和线上版本一直

3.【严格执行】master分支 release分支不允许直接push,只能merge

4.【严格执行】未测试通过的代码不允许merge到release

5.【严格执行】已经合并至release分支的代码如果突然中断上线一定要检查分支graph,并通知相关分支负责人回滚

6.【建议执行】新分支只能从master分出

7.【严格执行】commit备注规范请参照idea commit 提交模板规范

多分支并行开发，

当有多个分支并行开发且要同时进行测试or联调的时候，新建一个test分支。发布测试时，将feature分支合并到test分支提测（满足多个需求可以同时测，又验证了集成测试）。

命名：test-版本号 按序递增

合并后，test分支的pom对应feature分支最大版本号

示例：test-1.5.0

说明：

1.新增test分支的时间是晚于feature分支的

2.如果中途某个feature分支突然说不上线了，只需摒弃test分支，选择指定的分支上线即可。

远程分支重命名命令：

1. 重命名远程分支对应的本地分支

git branch -m oldbranch newbranch

2. 删除远程分支

git push origin :oldbranch

3. 上传新命名的本地分支

git push origin newbranch:newbranch

敏捷开发流程梳理