码迷,mamicode.com
首页 > 其他好文 > 详细

【Git管理篇】GitLab 版本分支管理策略(二)

时间:2020-03-05 11:52:24      阅读:121      评论:0      收藏:0      [点我收藏+]

标签:content   class   命名   resolve   pull   source   开发   front   关闭   

          我们采用目前的保留的分支体系:   master 、 develop(将feature、hotfix合到develop)、release

 一、代码分支

分支

说明

创建来源分支

代码来源

目标分支

代码输入方式

生命周期

命名规则★

★master

主干分支,通常作为代码基线,所有发布的代码最终都会合并到此分支。  

release、hotfix

develop

Pull request

长期

Master

★develop

开发分支,通常作为其他分支的源分支,也最终会合并回此分支

feature、

release、hotfix

develop

Pull request

长期

Develop

feature

功能分支,用于为未来的应用版本开发新的功能需求

develop

developer

develop

Merge

并入目标分支后,删除

Feature/{jira_issue_key}

★release

发布分支,用于辅助新版本发布的准备工作,例如小bug的修复,或者版本号的修改等等

develop

developer、

hotfix

Develop、master

Merge

并入目标分支后,删除

Release/{jira_issue_key}

hotfix

修复分支,用于正式版本的紧急修复

master

开发者

Develop、master、release

Merge

并入目标分支后,删除

Hotfix/{jira_issue_key}

 

二、功能开发

技术图片

 

研发

测试

审查

创建并推送功能分支

 

 

创建 feature → develop 的 pull request

 

 

代码审查

 

 

功能测试

 

 

合并代码到开发分支

 

 

关闭pull request

 

 

 三、版本发布

技术图片

 

 

 

研发

测试

审查

创建并推送发布分支

 

 

创建 realease → develop 的 pull request

 

 

创建 realease → master的 pull request

 

 

审查 realease → develop 的 pull request

 

 

审查 realease → master 的 pull request

 

 

发布测试

 

 

合并代码到开发分支

 

 

合并代码到主干分支

 

 

关闭realease → develop 的 pull request

 

 

关闭realease → master 的 pull request

 

 

创建代码标签

 

 

四、Hotfix修复

技术图片

 

 

 

研发

测试

审查

创建并推送修复分支

 

 

创建 hotfix → develop 的 pull request

 

 

创建 hotfix → release 的 pull request

 

 

创建 hotfix → master的 pull request

 

 

审查 hotfix → develop 的 pull request

 

 

审查 hotfix → release 的 pull request

 

 

审查 hotfix → master 的 pull request

 

 

发布测试

 

 

合并代码到开发分支

 

 

合并代码到发布分支

 

 

合并代码到主干分支

 

 

关闭hotfix → develop 的 pull request

 

 

关闭hotfix → release 的 pull request

 

 

关闭hotfix → master 的 pull request

 

 

创建代码标签

 

 

五、场景模拟

Master分支 :一定是最后一次 commit已经上线,或者 他已经顺利通过了 QA、PD、PO 的打磨锻造,分分钟拔出来上线。(ps:不用怕会祭天)

(1)常规开发

新建code库,库中 master和所有其他分支,只有项目负责人有写入权限

从code库中master克隆一个分支出来,命名为:branch_1.0.0   【develop】

开发人员在 此分支上修改,开发和自测完后,向 code库发起pull request,请求代码审查和合并

pro-master 进行代码审查、合并后,提交测试。头缺陷,继续在 branch_1.0.0 修复,然后发起pull request,如此循环,知道最后,测试完成,可以将 branch_1.0.0 上线

上线后,将此branch_1.0.0分支合并到msster,并给branch_1.0.0打上tag。  【ps:理论上,此时的 master和branch_1.0.0是完全一致的】

(2)并行开发

假定:branch_1.0.1 和 branch_1.0.2 同时并行开发

情况:

     第一种:  branch_1.0.1 先开发完,测试完,上线完之后,branch_1.0.2 才准备提测。 此时,需要在合并测试版本branch_1.0.2时,将master内容一起合并,合并之后再进行测试

     第二种:  branch_1.0.1 和 branch_1.0.2 同时开发完,可以合并成一个release版本, 或者 合并成到 branch_1.0.2 进行测试

     第三种: branch_1.0.1 开发完,测试完,未上线,branch_1.0.2 开发完,准备提测, 此时 操作和 第二种一样

     第四种: branch_1.0.1 和 branch_1.0.2 都开发完,需要同时测试(不建议),只能一个分支先测试完上线,另一个分支需要合并上线后的master再次测试,上线。

 

参考文档:https://blog.csdn.net/BoReFrontEnd/article/details/97391441

 

【Git管理篇】GitLab 版本分支管理策略(二)

标签:content   class   命名   resolve   pull   source   开发   front   关闭   

原文地址:https://www.cnblogs.com/dongv5/p/12419276.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!