首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

Git Flow 模型的增强版,可以是怎么样的,解决传统 Git Flow 的缺陷

这种复杂性更容易导致错误,并增加了修复错误所需的成本。 release 和 hotfix 分支需要“双重合并”——进入main分支,然后进入devlop分支。有时你会忘记兼顾两者。...与此同时,您可以开始在开发分支中开发新版本,这与在经典 Git Flow 中看到的优势相同。 当您的新版本被认为足够稳定时,将最终版本部署到生产环境中,并进行一次主开发合并,以获得所有的修复。...将当前主版本的更改通过补丁到新版本。 然后,重新执行发布过程:在当前主干的顶端标记并推送标记,在新发布分支的顶端删除并重新创建本地主分支,然后强制推送。 您可能不需要前面的标记,所以可以删除它。...新发布的分支现在是多余的,所以您也可以删除它。 您现在应该可以像往常一样使用新发行版了。通过传播紧急修补程序从主开发通过 cherry pick 或补丁完成。...以一种允许您的团队根据手工请求将构建版本从主环境部署到生产环境的方式配置 CI。 这些模式相对简单,但提供了支持日常开发操作的强大机制。

56230

增强版 Git Flow 模型

这种复杂性更容易导致错误,并增加了修复错误所需的成本。 release 和 hotfix 分支需要“双重合并”——进入main分支,然后进入devlop分支。有时你会忘记兼顾两者。...与此同时,您可以开始在开发分支中开发新版本,这与在经典 Git Flow 中看到的优势相同。 当您的新版本被认为足够稳定时,将最终版本部署到生产环境中,并进行一次主开发合并,以获得所有的修复。...将当前主版本的更改通过补丁到新版本。 然后,重新执行发布过程:在当前主干的顶端标记并推送标记,在新发布分支的顶端删除并重新创建本地主分支,然后强制推送。 您可能不需要前面的标记,所以可以删除它。...新发布的分支现在是多余的,所以您也可以删除它。 您现在应该可以像往常一样使用新发行版了。通过传播紧急修补程序从主开发通过 cherry pick 或补丁完成。...以一种允许您的团队根据手工请求将构建版本从主环境部署到生产环境的方式配置 CI。 这些模式相对简单,但提供了支持日常开发操作的强大机制。

24520
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    持续交付之基于Git Flow代码分支策略实践

    热修复分支:hotfix,针对现场紧急问题、bug修复的代码分支,修复完后合并到主分支、开发分支。 发版分支:release,版本发布分支,用于迭代版本发布。...:主分支,稳定版本 Hotfixes:补丁分支,稳定/预览版本或现场问题的应急处理 Release:预览分支,Bata版/测试与bug修复 Develop:开发分支,常规功能的新增与调整 Feature...分支合并时间 主分支:每个季度一个正式版本,于每个季度末合并发版;由预览分支、补丁分支合并;不允许直接Push代码,只能合并; 补丁(热修复)分支:随现场使用情况而定,可以打临时版本或补丁;由主分支替换而来...,修复完后合并到主分支、开发分支; 预览分支:版本发布分支,用于迭代版本发布。...紧急bug修复流程 git checkout hotfix //切换到hotfix分支git pull gitlab master //更新从远端主分支更新代码,会同时更新本地

    60720

    持续交付之基于Git Flow代码分支策略实践

    热修复分支:hotfix,针对现场紧急问题、bug修复的代码分支,修复完后合并到主分支、开发分支。 发版分支:release,版本发布分支,用于迭代版本发布。...:主分支,稳定版本 Hotfixes:补丁分支,稳定/预览版本或现场问题的应急处理 Release:预览分支,Bata版/测试与bug修复 Develop:开发分支,常规功能的新增与调整 Feature...分支合并时间 主分支:每个季度一个正式版本,于每个季度末合并发版;由预览分支、补丁分支合并;不允许直接Push代码,只能合并; 补丁(热修复)分支:随现场使用情况而定,可以打临时版本或补丁;由主分支替换而来...,修复完后合并到主分支、开发分支; 预览分支:版本发布分支,用于迭代版本发布。...紧急bug修复流程 git checkout hotfix //切换到hotfix分支git pull gitlab master //更新从远端主分支更新代码,会同时更新本地

    1.4K30

    带领前端小伙伴重温「Git Flow Workflow」

    Git Flow 长期分支 master develop master:主分支,这个大家应该不陌生。代码库应该有一个、且仅有一个主分支;提供用户正式使用的版本,都在这个主分支上发布。...develop:开发分支,日常使用的开发分支。从 master 分支上面分出来的,一般功能开发完成后合并到主分支,并且用主分支进行发布。...bug 这种东西大家都不陌生,hotfix 就是用来修补正式发布以后的 bug 的分支。从 master 分支上面分出来的,一般修复完成后合并到主分支以及开发分支,并且删除补丁分支,用主分支进行发布。...从 develop 分支上面分出来的,预发布结束以后,必须合并进 develop 和 master 分支。命名方式一般为 release/* 或 release-*。...修复完成后,将 release/x 补丁分支合并到 master 分支(使用 --no-ff 可以在 git 历史上清晰看见记录) git merge --no-ff release/x # 切换到

    32860

    带领前端小伙伴重温「Git Flow Workflow」

    Git Flow 长期分支 master develop master:主分支,这个大家应该不陌生。代码库应该有一个、且仅有一个主分支;提供用户正式使用的版本,都在这个主分支上发布。...develop:开发分支,日常使用的开发分支。从 master 分支上面分出来的,一般功能开发完成后合并到主分支,并且用主分支进行发布。...bug 这种东西大家都不陌生,hotfix 就是用来修补正式发布以后的 bug 的分支。从 master 分支上面分出来的,一般修复完成后合并到主分支以及开发分支,并且删除补丁分支,用主分支进行发布。...tag -a 1.1 # 合并完成删除 hotfix/x 补丁分支 git branch -d hotfix/x release:预发布分支。...从 develop 分支上面分出来的,预发布结束以后,必须合并进 develop 和 master 分支。命名方式一般为 release/* 或 release-*。

    56920

    持续交付之如何选型代码分支策略?

    热修复分支:hotfix,针对现场紧急问题、bug 修复的代码分支,修复完后合并到主分支、开发分支。 发版分支:release,版本发布分支,用于迭代版本发布。...:主分支,稳定版本 Hotfixes:补丁分支,稳定/预览版本或现场问题的应急处理 Release:预览分支,Bata版/测试与bug修复 Develop:开发分支,常规功能的新增与调整 Feature...:特性分支,同时可以有多个特性分支,代码合并后结束; 分支合并时间: 主分支:每个季度一个正式版本,于每个季度末合并发版;由预览分支、补丁分支合并;不允许直接 Push 代码,只能合并; 补丁(热修复)...分支:随现场使用情况而定,可以打临时版本或补丁;由主分支替换而来,修复完后合并到主分支、开发分支; 预览分支:版本发布分支,用于迭代版本发布。...分支发布的策略图如下所示: 代码管理后台:GitLab 主分支:master,开发主分支,对外可以随时编译发布的分支,不允许直接Push代码,只能请求合并(pull request)。

    2K20

    代码版本管理规范

    develop分支上进行提交 功能开发切换一个新的功能分支上,功能分支完成后需合并到develop分支 用release分支做版本发布,release用于预发布环境测试 release分支从开发分支切出来...,完成后需要合并到master分支和develop分支 预发布环境测试无误后,release分支合并到master分支,发布到生产环境测试 生产环境测试完成后release分支可以删除 生产环境运行中紧急修复采用...,因此经常面临分支切换,导致很繁琐 修补分支和发布分支设置繁琐,比如每次使用修补分支都需要同时合并到master和develop分支,但开发经常犯错误,比如忘记合并回develop分支 Github Flow...分支模型 面对git flow的繁琐,github flow分支模型仅具有功能分支和主分支,将所有内容合并到master分支中并进行部署,采用pull request方式进行代码合并,强调持续集成和连续交付...,主要是自动化测试 部署发布的时候,从master中摘取(cherry Pick)核心发布功能到”release-x.x.x-alpha”分支进行测试,并在其上进行修复 测试通过后,切换到”release-x.x.x

    2.9K51

    Git设置分支保护实现CodeReview卡点

    GitFlow模式的各分支说明 1) master 主分支 , 产品的功能全部实现后 , 最终在master分支对外发布 该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 ,...feature分支合并到develop之后 , 从develop分支克隆 主要用于提交给测试人员进行功能测试 , 测试过程中发现的BUG在本分支进行修复 , 修复完成上线后合并到develop/master...分支并推送(完成功能) , 打Tag 属于临时分支 , 功能上线后可选删除 5) hotfix 补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复 修复完毕后合并到develop.../master分支并推送 , 打Tag 属于临时分支 , 补丁修复上线后可选删除 所有hotfix分支的修改会进入到下一个release GitFlow 主要的工作流程 代码仓库的Owner设置master...9) 当进行一个release分支时 , 若dev分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上即合并dev到当前release分支 (因为当前release分支通过测试后会发布到线上

    1.7K30

    SourceTree的基本使用

    之间表示要合并的分支下的代码,>>>>>>> feature/F_feature_2表示了要合并的分支的分支名称, 根据情况区分要保留的代码,要删除的代码,最后再删除的修复补丁 正式版本发布后,develop可继续进行后续开发,当正式版本出现问题时,需要进行问题的修改,可以在master分支建立修改补丁hotfix。...将当前分支切换到master,点击“Git工作流”,选择“建立新的修复补丁” ? ? 预览中hotfix分支是从master拉去出来的,输入修复补丁名,点确定 ?...合并冲突 在完成发布版本和完成修复补丁时,如果遇到冲突,可仿照上述2.5.进行冲突修改,再进行后续操作。 ?  ...之间表示要合并的分支下的代码,>>>>>>> feature/F_feature_2表示了要合并的分支的分支名称, 根据情况区分要保留的代码,要删除的代码,最后再删除<<<<<<< HEAD、=====

    1.4K40

    架构师分享 高效团队的gitlab flow最佳实践

    第一步:根据需求,从master拉出新分支,不区分功能分支或补丁分支。 第二步:新分支开发完成后,或者需要讨论的时候,就向master发起一个pull request(简称PR)。...开发完成后,在迭代结束前,合入master分支 master分支合并后,自动cicd到dev环境 开发自测通过后,从master拉取要发布的分支,release-$version,将这个分支部署到测试环境进行测试...测出的bug,通过从release-versio拉出分支进行修复,修复完成后,再合入release-versio 正式发布版本,如果上线后,又有bug,根据5的方式处理 等发布版本稳定后,将release...测试发布 master分支,自动部署到开发环境(dev) 功能开发完成,并自测通过后,代码合并到待发布版本, 分支规则: release-version 版本规则 主版本号.次版本号 构建时,自动增加修订号...bug修复 需要修改bug时,从release-version新拉分支,修改完成后再合并到release-version分支. Q: 从release-$version拉的分支,如何测试?

    4.3K10

    高效团队的gitlab flow最佳实践

    第一步:根据需求,从master拉出新分支,不区分功能分支或补丁分支。 第二步:新分支开发完成后,或者需要讨论的时候,就向master发起一个pull request(简称PR)。...开发完成后,在迭代结束前,合入master分支 master分支合并后,自动cicd到dev环境 开发自测通过后,从master拉取要发布的分支,release-$version,将这个分支部署到测试环境进行测试...测出的bug,通过从release-versio拉出分支进行修复,修复完成后,再合入release-versio 正式发布版本,如果上线后,又有bug,根据5的方式处理 等发布版本稳定后,将release...测试发布 master分支,自动部署到开发环境(dev) 功能开发完成,并自测通过后,代码合并到待发布版本, 分支规则: release-version 版本规则 主版本号.次版本号 构建时,自动增加修订号...bug修复 需要修改bug时,从release-version新拉分支,修改完成后再合并到release-version分支. Q: 从release-$version拉的分支,如何测试?

    4.2K31

    Sourcetree使用教程

    ,由于master分支是主分支,项目多人开发的情况下,很容易造成冲突。...合并分支 将两个分支的代码合并,比如主分支事master,然后在test分支进行开发,开发完成后需要保持master事最新版本,所以需要将test分支合并到master。...4) release,预发布版本,介于develop和master之间的一个版本,主要用于测试 5) hotfix,修复补丁,用于修复master上的bug,直接作用于master 当开发中需要增加一个新的功能时...开发完成你们合并的时候就有冲突产生,参照下面的冲突解决即可。 当开发到一定阶段,可以发布测试版本时,可以从develop分支,建立release分支,进入预发布测试阶段。...点击“Git工作流”,选择“建立新的发布版本” 发版后线上有bug需要解决可以建立新的修复补丁: 具体操作参考上面的新建功能分支。

    4.5K22

    图解Gitlab Flow

    Feature Branch (功能分支): 每个新功能或修复从主分支分出,开发完成后合并回主分支。 Release Branch (发布分支): 用于准备发布,进行 QA 测试、错误修复等。...Hotfix Branch (热修复分支): 紧急问题修复分支,从主分支创建,修复完成后直接合并回主分支。 2. 示例说明 场景:一个电子商务平台的开发流程。...发布准备阶段: 需求:即将发布 v1.1.0 版本。 操作:从主分支创建 release/v1.1.0,进行全面测试和优化,发现问题在分支中修复。...操作:从主分支创建 hotfix/fix-payment-bug,快速修复后提交合并请求。 结果:修复代码经过审查,合并到主分支并立即部署。 3....优势总结 清晰的分支管理:明确了功能开发、发布准备、和紧急修复的流程。 支持持续集成/交付:主分支保持可部署状态。 适配多种开发场景:灵活适用于小型团队和企业级开发。

    12910

    【Git】六、企业级开发模型

    为了开发调试方便,一般打开全部错误报告和测试工具,是最基础的环境。 测试环境:一个程序在测试环境工作不正常,那么肯定不能把它发布到生产机上。该环境是 开发环境到生产环境的过渡环境。...所以预发布环境是你的产品质量最后一道防线,因为下一步你的项目就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内,为单独的一些机器。...Git 分支设计规范 ​ 环境有了概念后,那么对于开发人员来说,一般会针对不同的环境来设计分支,例如: 分支 名称 适用环境 master 主分支 生产环境 release 预发布分支 预发布/测试环境...用于部署到正式发布环境,一般由合并 release 分支得到 主分支作为稳定的唯一代码库,任何情况下不允许直接在 master 分支上修改代码 产品的功能全部实现后,最终在 master 分支对外发布,...,便将其删除 hotfix分支 hotfix 分支为 线上 bug 修复分支或叫补丁分支,主要用于对线上的版本进行 bug 修复。

    10310

    生产环境hotfix部署流程

    针对生产环境发布新版本后有bug需要紧急修复的情况,协作流程思路:新建对应的hotfix补丁分支,相关开发人员基于hotfix分支进行bug修复,修复完毕验证无误后,同样通过Merge Request合并至主仓库...当相关人员代码开发修复后,处理Merge Request,基于主仓库的B-R-XYPJ-S-CAMS-0.11.0分支再次构建发布新版本,每次发布生产后,再次打tag,同时tag中小版本号递增,例如修复若干...bug重新发布后,新的tag名为:R-XYPJ-S-CAMS-0.11.1,再修复若干bug重新发布后,新的tag名为R-XYPJ-S-CAMS-0.11.2,以此递增。...注意必要情况下使用cherry-pick,例如B-R-XYPJ-S-CAMS-0.11.0上修复的内容同时需要合并到master,则:git checkout master,切换到master分支,然后执行...git cherry-pick [commit-id],合并无误后,push到origin master并提MR到upstream master。

    91210

    团队开发Git分支管理策略

    开发生涯的前三年都是使用 svn,回首放佛如前世。自从用了 git ,整个人都神经了。 下面的内容肯定不是什么教你如何用git提交代码,合并分支之类的。...我的选择 我选择了 Git flow,它的主要特点是,长期存在两个分支: 主分支master 开发分支develop 然后,存在三种辅助分支,都是短期的,并且一半情况下只应该存在本地,不要提交到远程库。...什么时候要功能分支? 当你拿到一个需求,或者不是一个立马需求上线的bug修复,那么就应该从 develop 开一个分支出来,完成这部分工作。完成后合并到 develop 分支。 ?...就应该从develop产生一个release分支,交给测试,如果有bug直接在上面修改。全部完成后,合并回develop,并且合并到master。 关于这个分支我得再多说几句。...因为这是非常重要的一步,如果我们使用了 git 钩子,当合并到 master 的时候,会自动发布到线上,所以这是临上线的最后一道屏障。 同时这里也解决了我一个疑惑,测试如何参与到git的每个分支中来?

    1.4K20

    1 什么是 Git

    Git Flow 的常用分支 生产分支(master)‌ Master分支是仓库的主分支,这个分支包含最近发布到生产环境的代码,最近发布的Release, 这个分支只能从其他分支合并,不能在这个分支直接修改‌...分支合并回Master和Develop分支‌ 发布分支(release)‌ 当你需要发布一个新功能的时候,要基于Develop分支创建一个Release分支,在Release分支测试并修复bug...,完成release后,把release合并到master和develop分支‌ 开发分支(develop)‌ 这个分支是我们的主开发分支,包含所有要发布到下一个Release的代码,这个主要合并与其他分支...新功能合并到develop分支之后,我们想把新功能发布到生产环境,首先基于develop分支创建release分支,然后在release分支测试完成之后,把release分别合并到master分支和develop...我们把代码发布到了生产环境,用户在使用的时候给我们反馈了一个bug,这时我们需要基于master分支创建一个hotfix 分支,用于修复bug,bug修好之后,把 hotfix 分支分别合并到master

    8800
    领券