分支开发规范

目录

• 背景和价值
• 分支介绍
  • master分支
  • Hot fix分支
  • release分支
  • develop分支
  • feature分支
  • bug fix分支
• 流程
  • 项目启动
  • 开发本地自测
  • 开发环境联调
  • 测试环境测试
  • 测试环境BUG修复
  • UAT测试
  • 上线
  • 上线后一天
  • 生成有故障，需要紧急修复
• 多项目并行情况
• 环境规范
• 分支命名规范
• 冲突解决规范
• 参考资料

背景和价值

基于git flow做了简化。

分支介绍

【总结】

• 只有master和dev是永久性分支，其他都是临时性分支。
• release/master分支合入；每次合入需评审

master分支

主干分支，也是正式发布版本的分支，其包含可以部署到生产环境中的代码，通常情况下只允许其他分支将代码合入，不允许向Master分支直接提交代码（对应生产环境）。

Hot fix分支

热修复分支，生产环境发现新Bug时创建的临时分支，问题验证通过后，合并到Master和Develop分支。

release分支

从master分支克隆，主要用于提交给测试人员进行功能测试。每个迭代需要拉新的release分支。当出现多迭代并行的时候，需要拉多个release分支。如order psa，拉 order-release-0204 用这个分支上test，sit测试 。
【NOTICE】为什么每个迭代都拉release分支？因为relase分支是要按迭代上线的。

develop分支

开发联调分支，dev是永久性分支，基于master分支克隆，包含所有要发布到下一个release的代码及部分跨迭代的需求。
【NOTICE】为什么dev是永久分支？因为有些项目不会按迭代上线。有些项目要开发几个月才上线。

feature分支

特性分支，从master分支拉出（常规迭代从master拉出，如果是专项，参考专项的说明），每个新特性的开发对应一个特性分支，用于开发人员提交代码并进行自测。 建议一个需求建一个feature分支。自测完成后，会将Feature分支的代码合并至Develop分支，在开发环境测试。
原则上一个开发一个特性拉一个feature分支，
【NOTICE】如果同一个psa如果2个开发编写的代码存在依赖，可以公用一个feature分支。feature分支在迭代结束后就可以删除。
【NOTICE】当两个开发在同一个模块代码产生依赖的时候，开发人员需要使用同一个feature，在需求评审、设计时，TL要尽可能识别到这种情况；如果在开发中才发现，则需要及时反馈合并feature进行开发

bug fix分支

测试修复分支，用于测试环境修复bug使用。
【NOTICE】为什么不直接在feature上直接修改bug? 如果在feature上修改bug,合并到release分支存在的冲突,在下次合并的时候冲突会再次出现.

流程

项目启动

PSA负责人从master拉release分支。 开发从master拉feature分支

开发本地自测

在本地使用feature分支自测。
如果A 依赖别的member B写的代码，把我的代码合并到dev，member B合并到dev 一起测试。把dev拉到本地debug。

开发环境联调

feature 合并到dev环境

测试环境测试

feature 合并到release分支测试

测试环境BUG修复

• 提测。feature分支合并到release分支。
• 从release分支拉 bug-fix分支，测试好后合并到 release分支

UAT测试

• release分支部署到UAT测试
• 发版当天或者前一天，把release分支合并到master在UAT复测
• UAT环境代码已经合并到mater测试出bug：一般情况下，这种bug不会太严重，直接从master拉 bug-fix分支合并到master复测即可
  *【特殊情况】 上线当天，当前迭代上线代码已合入master分支部署至预生产环境；发现了生产bug需要紧急修复，此时基于上一次上线发布的tag拉取hotfix分支

上线

master分支上线并打tag

上线后一天

master分支代码合并到dev分支

生成有故障，需要紧急修复

• 从master拉hotfix分支，在本地调试后，上DEV开发测试后，发UAT测试通过后上线。
  没必要走test - sit 流程。 正常dev-test-sit-uat的意义在于，团队效率最大化。如果直接从dev到uat势必大量的返工，浪费开发和测试的时间。生产出现故障时间很紧迫，代码改动一般不会太大，而且UAT具备跨系统联调条件。直接在UAT上测试通过后发版是最快的。
• hotfix发布后，把master分支合并到dev分支
• 合并master代码至非常规迭代的release分支
• 同步master代码至当前开发中的feature分支

多项目并行情况

有时候除了常规迭代，还会有欧洲专项，印度专项。专项的跨度几个月时间。
存在问题和解决

1. 公用同一个长期dev分支，会导致代码严重冲突。 如果专项是大版本，存在大冲突的可能，拉取独立的dev分支。 如果专项是小版本跟常规迭代冲突不大，可以公用dev 长期分支。
2. 上线时间节奏不一样，不能跟常规迭代的release分支共享。 拉独立的release分支。
3. 不能从master拉feature了，因为master没有专项的代码。 feature从专项的release分支。

环境规范

UAT：生产预发布环境。
sit：测试环境1，具备集成测试能力
test：测试环境2，不具备集成测试能力
dev：开发自测环境
有时候有多个项目并行，还会新增osit，otest 。 o是海外的意思

分支命名规范

分支名称	命名规范	对应环境
master
hotfix	hotfix/工号-yyyymmdd	UAT
release	release-XXX-yyyymmdd XXX为项目专项，比如INDIA,EUR,如果是常规为空	TEST/SIT/UAT
develop		dev
feature	工号-需求id	本地
bugfix	bugfix/工号-yyyymmdd	TEST/SIT/UAT

冲突解决规范

由于releases是保护分支，不允许直接提交，需要经过评审才能合入。指定冲突解决规范

从dev进行cherry-pick到release或者feature合并到release分支存在冲突时；
需要先从release分支拉取一个中间分支，命名建议为feature分支名-merge-to-releaseXXX
例子：feature/80370223-0310-merge-to-release20230315
拉取中间分支后，把需求开发的feature分支合并到该分支解决冲突，解决完后再把中间分支提交合并到对应的release分支

参考资料