EWM分支策略
2022-08-25 22:01:32 1 举报
登录查看完整内容
基于Git Flow的分支管理策略 实现小步快跑的版本管理
作者其他创作
大纲/内容
否
使用场景
集成测试分支
Branch
用户验证uat/ver-*
是
集成测试过程中出现的bug，需要在源功能分支上修复完成并进行本地测试后合并至develop，再由develop合并至对应的sit分支上
主分支\\生产分支
避免merge时出现冲突先同步develop上的更新
sit通过后，拉取uat分支，用户验证
热修复完成后，需merge到master&develop&Testing分支
feature/B
修复上线后，hotfix分支的代码需合并到develop分支以及正在测试的测试分支
标记分支
预发布版本的分支用户验证完成后合并代码至master分支
开发集成分支
用户验证分支
命名规则
名称
develop分支合并完成后开始进行sit集成测试时，从develop分支拉取
主分支master\\main
以develop为基础的功能分支，完成功能开发后为避免代码评审时出现冲突，先从develop中拉取最新代码，本地解决完冲突后进行代码的推送以及向develop的合并申请
集成测试sit/ver-*
长期
有生命周期，版本发布后清理
主开发分支develop
需要修复生产紧急bug时，从master分支中拉取
Tag-v0.1
详细记录此次发布版本的内容，便于溯源
功能分支合并到develop后拉取sit分支
根据jira下发的需求进行新功能的开发
功能分支
热修复分支
描述
fix test bug
Tag-v2.0-Beta
热修复hotfix-*
sit_yyMMdd(上线窗口日期)
是否多条
功能/测试分支的源分支接收紧急bug修复合并接收功能分支完成合并
功能开发分支
有生命周期，视情况清理
Tag-v1.0
feature/A
hotfix_yyMMdd(修复上线日期)
feature
分支
有生命周期，修复上线后清理
持续迭代
Tag-v3.0
投产前从master分支拉取
用户验证过程中出现的bug，同样需要在对应的功能分支上开发完成，通过本地测试、sit测试后才可合并至对应的用户验证分支，
feature_jiraIssueID_yyMMdd
测试分支
Tag
release_版本号_yyMMdd(投产日期)
Tag-v0.2-Hotfix
功能分支来自于develop分支
Tag-v0.3-Hotfix
固定为：main，git旧版本叫master
生命周期
固定为：develop
生产环境bug再现与调查新的功能发布紧急bug修正发布
EWM代码分支管理策略
uat_yyMMdd(上线窗口日期)
专人负责，分支受保护，不接受编码，不允许push，只接受merge，长期稳定，与生产版本保持一致
SCM版本管理员负责，分支受保护，不接受编码，不允许push，只接受merge，主集成分支，功能分支的基线合并时必需进行代码评审
0 条评论
回复 删除
下一页
