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

Git流程应该从发布分支还是主/主干分支发布到生产

Git流程应该从发布分支发布到生产。

在Git中,发布分支是指用于发布软件的稳定版本的分支。通常情况下,开发人员会在主分支(也称为主干分支)上进行开发工作,而发布分支则是从主分支上创建出来的。发布分支上的代码经过测试和验证后,可以被部署到生产环境中。

发布分支的使用有以下几个优势:

  1. 稳定性:发布分支上的代码经过测试和验证,相对于主分支上的开发代码更加稳定可靠。
  2. 版本控制:通过发布分支,可以对软件的不同版本进行管理和控制,方便回滚和追溯。
  3. 并行开发:发布分支可以支持多个并行的开发任务,不会影响主分支上的开发工作。

发布分支适用于以下场景:

  1. 发布软件版本:当需要发布一个新的软件版本时,可以从主分支上创建一个发布分支,并在该分支上进行版本的测试和准备工作。
  2. 紧急修复:当生产环境中出现紧急问题需要修复时,可以从发布分支上创建一个修复分支,并在该分支上进行紧急修复工作。

腾讯云提供了一系列与Git相关的产品和服务,包括代码托管、持续集成和持续部署等。其中,腾讯云代码托管(CodeCommit)是一项安全、可扩展的托管服务,可帮助团队协作开发、管理代码版本,并提供了与其他腾讯云产品的集成能力。您可以通过以下链接了解更多关于腾讯云代码托管的信息:https://cloud.tencent.com/product/cc

请注意,以上答案仅供参考,具体的Git流程和发布策略应根据团队的实际情况和需求进行调整和制定。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

Git 分支管理策略汇总

branch (功能分支) release branch (预发布分支) hotfix branch (热修复分支) master 首先,代码库应该有一个、且仅有一个分支。...master 分支的代码永远是稳定的,可以随时发布生产环境。 develop develop 分支用于日常开发,保存了开发过程中最新的代码。...比如,开发环境的分支是 master,预发环境的分支是 pre-production,生产环境的分支是 production。 开发分支 master 用于发布测试环境,该分支为受保护的分支。...最后,再分享三点小建议: 临时分支应该存在太久,每个分支应尽量保持精简,用完即删 工作流应该尽量简单,同时方便回滚 工作流程应该符合我们的项目发布计划 以上就是本文的全部内容,如果觉得还不错的话欢迎点赞...--- 参考文章: Git 分支管理策略与工作流程 Git 分支管理策略总结 一个完美的 Git 分支管理模型 Git 工作流程 Git 分支管理策略 分支模型与主干开发

1.1K10

认识 GitFlow

GitFlow 介绍 1.1 什么是 GitFlow GitFlow 是一种 Git 工作流,这个工作流程围绕着 project 的发布 (release) 定义了一个严格的如何建立分支的模型。...这样做的好处是: 1.还处于半成品状态的 feature 不会影响主干2.各个开发人员之间做自己的分支,互不干扰3.主干永远处于可编译、可运行的状态 GitFlow 则在这个基础上更进一步,规定了如何建立...只能从其他分支合并,不能直接修改 Release 发布分支,基于 Develop 分支创建,待发布完成后合并到 Develop 和 Production 分支去 Develop 开发分支,包含所有要发布下一个...与分支不同,这些分支总是有有限的生命时间,因为它们最终将被删除。 1.3.1 分支(Master) 分支上存放的是最稳定的正式版本,并且该分支的代码应该是随时可在生产环境中使用的代码。...当开发分支到达一个稳定的点并准备好发布时,应该该点拉取一个预发分支并附上发布版本号。也有人称开发分支为集成分支,因为会基于该分支和持续集成工具做自动化的构建。

200
  • 版本分支管理标准 - Trunk Based Development 主干开发模型

    ---- Preface 在之前的博文中我们介绍了 Git Flow 分支模型,正如文中所说,Git Flow 偏向于控制管理,使用了较多的分支流程颇为复杂。...并没有做到持续交付,在 Git Flow 分支模型下,发布是非常有计划的,一个 feature 必须要经过一系列步骤才能到达生产环境,在时间上平均一个 feature 都要等待 两周时间才能长线,这样的等待并非是需求上的...它摒弃了 Git Flow 中繁杂的分支, 只保留一个分支 master 。...此举可 避免分支合并的困扰,保证随时拥有可发布的版本 。“主干”这个词隐喻了树木生长的场景,树木最粗最长的部位是主干分支主干分离出来但是长度有限。 ?...根据预期的发布频率,你的团队或许需要实时主干分支创建 发布分支 以确保发布版本不会有新的提交,这些分支应该发布完成后一段时间内删除。

    5.8K31

    深入解析 Git 分支策略:如何为团队选择最优开发工作流程

    主要分支:master:生产环境的分支,始终保持可发布的状态。develop:开发分支,所有新功能的开发都会在此分支进行。...hotfix 分支:用于紧急修复生产环境的问题,直接 master 创建并最终合并回 master 和 develop。...示例代码:在主干开发中,开发人员直接在分支上进行小的功能迭代:# 切换到 main 分支并确保最新git checkout maingit pull origin main# 创建一个短期开发分支git...持续交付Trunk Based Development 的一个核心思想是尽量保持分支始终可部署。因此,团队应搭建自动化部署管道,在合并到 main 分支后,立即部署测试或生产环境。...# 删除 release 分支git branch -d release/1.0.03. hotfix 分支的紧急修复生产环境遇到紧急问题时,可以直接 master 分支创建 hotfix 分支,进行快速修复后立即发布

    11820

    【操作】git版本控制-相关工作流

    git工作流】定义为基于git版本控制工具,通过但不限于git命令的正确使用,用于完成版本控制,软件交付的整个流程规范。...相关术语 master主干 分支,产品的功能全部实现后,最终在master分支对外发布。用于生产环境发布的完整代码库版本。master主干长期存在,并与生产环境的版本保持一致。...主要使用git check -b 命令 Git版本控制,主要约定如下 开发人员以分支代码为基准进行开发,测试,并发布测试环境。以主干代码为基准进行灰度环境,生产环境上线部署。...原则上,当前主干代码应该以当前线上运行的实际代码保持一致。 主干合并规则 用于经过测试同事验证通过的开发分支,开发人员收到测试邮件之后操作,将开发完成的工作合并到主干分支。...本文着重提出了业界主流的三种git工作流方式,以及每种工作流的主要特点,并没有细化具体的使用场景和命令详情,给出了一些官方链接。如果按照武学小说来说,算是三种流派。

    81630

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

    主干开发(TBD) 主干开发是一个源代码控制的分支模型,开发者在一个称为 “trunk” 的分支Git 称 master)中对代码进行协作,除了发布分支外没有其他开发分支。...以后的改 Bug 和功能增强,都是提交到主干,必要时 cherry-pick (选择部分变更集合并到其他分支发布分支。与主干长期并行的特性分支极为少见。...,修复完后合并到分支、开发分支; 预览分支:版本发布分支,用于迭代版本发布。...紧急bug修复流程 git checkout hotfix //切换到hotfix分支git pull gitlab master //更新远端分支更新代码,会同时更新本地...合并代码分支,在gitlab上操作,发送Push Request 日常特性开发 推荐日常开发中多创建本地特性分支,标准流程如下: git checkout -b dev-rpccompress dev

    60220

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

    主干开发(TBD) 主干开发是一个源代码控制的分支模型,开发者在一个称为 “trunk” 的分支Git 称 master)中对代码进行协作,除了发布分支外没有其他开发分支。...以后的改 Bug 和功能增强,都是提交到主干,必要时 cherry-pick (选择部分变更集合并到其他分支发布分支。与主干长期并行的特性分支极为少见。...,修复完后合并到分支、开发分支; 预览分支:版本发布分支,用于迭代版本发布。...紧急bug修复流程 git checkout hotfix //切换到hotfix分支git pull gitlab master //更新远端分支更新代码,会同时更新本地...合并代码分支,在gitlab上操作,发送Push Request 日常特性开发 推荐日常开发中多创建本地特性分支,标准流程如下: git checkout -b dev-rpccompress dev

    1.3K30

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

    git flowgitlab flow git flow 先说git flow,大概是这样的。 ? 然后,我们老的git规范是参考git flow实现的。 ?...它是 Github.com 使用的工作流程。 ? 整个流程: ? 第一步:根据需求,master拉出新分支,不区分功能分支或补丁分支。...团队git规范 综合上面的介绍,我们决定采用gitlab flow,按照版本发布的模式实施,具体来说: 新的迭代开始,所有开发人员主干master拉个人分支开发特性, 分支命名规范 feature-name...开发完成后,在迭代结束前,合入master分支 master分支合并后,自动cicddev环境 开发自测通过后,master拉取要发布分支,release-$version,将这个分支部署测试环境进行测试...测试发布 master分支,自动部署开发环境(dev) 功能开发完成,并自测通过后,代码合并到待发布版本, 分支规则: release-version 版本规则 版本号.次版本号 构建时,自动增加修订号

    4.3K10

    【规范】Git分支管理,看看我司是咋整的

    维护分支稳定,避免未完成代码干扰生产环境。支持敏捷开发,适应快速迭代和持续集成。便于问题解决,快速定位错误来源。新人快速上手,标准化流程易于理解。促进代码复用,鼓励模块化开发。...分支主干分支具有分支保护权限,只有运维有权限进行合并分支分支模型用途master主干分支,正式版本代码归档 develop开发分支,团队成员日常开发的分支 doc文档分支,SQL脚本、配置等 辅助分支...:属于临时分支,当功能合并主干后,会删除清理掉分支模型用途featuredevelop拉取开发的功能分支 hotfixbug修复分支 3.Git分支在实际开发中使用流程 举个例子 2024年7月3日,...开发环境测试结束,功能开发分支拉出去掉快照标识的预生产分支 ✅有什么好处?...,拉取feature-javadog-v2.1.1-20240703 预生产分支,并打出对应tag,然后发布生产五.

    44162

    Git开发、发布、缺陷分离模型概述(支持masterdevelopfeaturereleasehotfix类型分支

    除此之外,Git还提供了强大的分支和合并功能,可以让开发人员在不影响主干的情况下创建和测试新功能。Git有什么作用?  ...分支master分支分支,包含了已经发布生产环境的稳定,可靠版本的代码。...一般情况下,master分支应该只用于发布新版本,而不应该直接修改或提交新的功能。创建流程:所有的发布代码都在master分支上合并完成。...feature分支feature分支develop分支创建的分支,通常用于开发新功能。每个新功能都应该develop分支开始,并在一个独立的feature分支上进行开发工作。...将该分支合并回master分支作为新的发布版本。将该分支合并回develop分支,以便后续的开发工作。hotfix分支hotfix分支master分支创建的分支,用于在生产环境中紧急修复问题。

    49120

    Git开发、发布、缺陷分离模型概述(支持masterdevelopfeaturereleasehotfix类型分支

    除此之外,Git还提供了强大的分支和合并功能,可以让开发人员在不影响主干的情况下创建和测试新功能。 Git有什么作用?   ...分支 master分支分支,包含了已经发布生产环境的稳定,可靠版本的代码。...一般情况下,master分支应该只用于发布新版本,而不应该直接修改或提交新的功能。 创建流程: 所有的发布代码都在master分支上合并完成。...feature分支 feature分支develop分支创建的分支,通常用于开发新功能。每个新功能都应该develop分支开始,并在一个独立的feature分支上进行开发工作。...hotfix分支 hotfix分支master分支创建的分支,用于在生产环境中紧急修复问题。修复完毕后,该分支将会被合并回master和develop分支

    47620

    高效团队的gitlab flow最佳实践

    git flowgitlab flow git flow 先说git flow,大概是这样的。 ? 然后,我们老的git规范是参考git flow实现的。 ?...它是 Github.com 使用的工作流程。 ? 整个流程: ? 第一步:根据需求,master拉出新分支,不区分功能分支或补丁分支。...团队git规范 综合上面的介绍,我们决定采用gitlab flow,按照版本发布的模式实施,具体来说: 新的迭代开始,所有开发人员主干master拉个人分支开发特性, 分支命名规范 feature-name...开发完成后,在迭代结束前,合入master分支 master分支合并后,自动cicddev环境 开发自测通过后,master拉取要发布分支,release-$version,将这个分支部署测试环境进行测试...测试发布 master分支,自动部署开发环境(dev) 功能开发完成,并自测通过后,代码合并到待发布版本, 分支规则: release-version 版本规则 版本号.次版本号 构建时,自动增加修订号

    4.2K31

    关于持续交付中Git分支管理的思考

    所以假设不再有提交的分支其实是可以被废弃的。我又计算了一下分支被创建(begin_time)销毁(last_push_time)总共存在了多长时间。...更不用说git commit的规范了,不方便回溯。 存在周期长的分支问题暴露了这么多,最后剩下的「较短周期」的分支应该总没问题了吧?...但是分支开发模式,其实本质上就是与持续集成的理念相互冲突的。持续集成是希望每次修改都尽早的提交到主干主干总是处于最完整和最新的可用状态,充分验证后就可以用它来进行生产部署。...「主干开发,分支集成」 来到发布前的集成测试节点了,功能已经全部开发完毕,通常这时候客户端团队就会代码中拉出「发布分支。...持续交付建议的方式是频繁的提交代码,并且最好工作在主干上,这样一来修改对所有项目成员都快速可见,然后通过持续集成的机制,对修改触发快速的自动化验证和反馈,再往后如果能通过各种维度的验证测试,最终将成为潜在可发布和部署生产环境的中版本

    2.1K62

    我们的好兄弟Git,一路走好!

    如果需要发布开发环境,所有人的代码都需要合并到develop,并且只能用develop分支进行发布开发环境。...缺点就是一个项目多个需求开发上线,需要合并多次代码,develop、teestrelease都要分别合并一次代码并且解决冲突。...来自阿里云效 这个分支可以一直用来发布日常(理解成开发或者测试环境合体)、预发和生产环境。 那如果多个需求同时在开发有冲突不需要合并代码吗?...这个规则对于预发和生产环境也是同理。 整个开发过程,我们不需要管各种分支,只需要一个feature功能分支用于发布各个环境,最终发布完成之后代码自动合并到master分支(可选项,也可以不合并)。...整个模式看下来就是集成了各个模式的特点,参考了Git Flow的分支的特点,只不过其他的分支不用开发人员关心,基于主干master拉出分支开发,自动合并又像是TrunkBased的做法,最终整个流程对于开发人员体验下来又像是更简化版的

    43720

    Git 开发规范

    这里先要明确几个基本概念master/main:分支,最终所有需要发布的有效代码都会合并到该分支develop:开发分支,所有开发内容都是基于 develop 分支创建 feature 分支feature...hotfix:热修复分支,线上出了紧急 bug,需要专门分支处理从上图可以看出,使用 git flow 开发步骤还是比较多的: develop 创建一个 feature 分支开发并自测完 feature...生产分支则类似于 release 分支,但是是 master 拉取出来,用来代表生产部署的代码版本。...trunk-based development与 github flow 差别很大,认为应该在 master(主干)上开发,使用 release 分支进行发布,理由是短期的开发任务不需要整的那么麻烦,测试什么的在提交到...其实,总结下来,一个健全的开发团队的分支管理应该满足以下条件:有一个永远有效、能反应生产部署代码的分支,可以随时发布有一个能持续集成、体现开发进度的分支,能够帮助提早发现集成问题Commit Message

    7910

    【DevOps实践】企业应用场景众多,怎样选择合适的代码分支模型?

    因此,企业的研发团队通常需要慎重地选择代码分支策略应用。 代码分支大模型的原则上分为三类,一类是主干开发分支发布,一类是分支开发主干发布,还有一类是主干开发主干发布。...Git flow存在两个长期的独立分支分支master和开发分支develop,分支用于版本发布分支的每个版本都是质量稳定和功能齐全的发布版。开发分支用于日常开发工作,存放最新的开发版代码。...master上创建新分支进行功能开发、问题修复等,这些分支通过pull request将代码合并到master。 为了保证分支的代码质量,master的权限只开放给一部分人。...相同之处是也存在一个长期分支mater,master上创建新分支进行功能开发、问题修复等,结束后合并回master。...TBD flow没有pull或者push request,要求开发人员尽快把代码提交到主干分支,但是TBD flow缺乏严格的流程来保证每一份提交代码的质量,如果一些项目开发人员众多且水平不一,同时工作在分支上可能会在产品发布时才发现不可预知的问题

    89630

    团队如何选择合适的Git分支策略?

    Git flow图片图片Git flow存在两个长期的独立分支分支master和开发分支develop,分支: 用于版本发布分支的每个版本都是质量稳定和功能齐全的发布版。...Git flow的优点在于流程清晰,分支管理严格,适用于发布周期比较长的“版本发布”,发布周期可能是几周,几个月,甚至更长时间。...TBD flow没有pull或者push request,要求开发人员尽快把代码提交到主干分支,但是TBD flow缺乏严格的流程来保证每一份提交代码的质量,如果一些项目开发人员众多且水平不一,同时工作在分支上可能会在产品发布时才发现不可预知的问题...当master上已经包含了某个发布所需要的所有功能,并且没有已知的严重问题,此时由SCM分支上创建Release分支准备系统集成测试,和Git flow相同,在此分支上不再进行新功能的开发,仅在这个分支上进行修复问题...在每个Release分支正式发布前可能还需要将分支上的一部分关键问题的修复选择性地同步(Cherry-pick)Release分支,这个操作也是由SCM完成。

    77400

    关于制定 gitflow 工作流的思考和总结

    git 工作流这个并不是只是前端开发只需要掌握的技能,而是程序员必备技能。它更多的是项目管理的角度和根据项目的实际情况出发而制定出来的一个开发流程的标准。...如下图: git-mark-1.png master 主干 master 是项目的主干代码,最终代码的合并和 clone 以这个主干为基准,master 的主干的代码只接受 merge request,...应该将确定好的代码 feature 直接合并到 master ,而 test 仅仅只是一个用来发布CI推送测试环境的分支。...同时,如果有微调的地方或者需要修改的地方,开发还是可以在 dev 中进行修改,自测通过之后再同步 test 分支也就是 CI 测试环境。...这样开发和测试不会相互干扰,如图: git-mark-5.png feture 分支 feature 分支就是功能分支,建议是一个模块就拉一条分支。但是,在实际开发中还是要看情况。

    1.3K141

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

    与经典 Git 流程的区别: Releases and Hotfixes 让我们来看看发布周期,因为这是你要做的主要事情。当我们想要发布开发中积累的内容时,它严格来说是 main 的超集。...与此同时,您可以开始在开发分支中开发新版本,这与在经典 Git Flow 中看到的优势相同。 当您的新版本被认为足够稳定时,将最终版本部署生产环境中,并进行一次开发合并,以获得所有的修复。...将当前版本的更改通过补丁新版本。 然后,重新执行发布过程:在当前主干的顶端标记并推送标记,在新发布分支的顶端删除并重新创建本地主分支,然后强制推送。 您可能不需要前面的标记,所以可以删除它。...新发布分支现在是多余的,所以您也可以删除它。 您现在应该可以像往常一样使用新发行版了。通过传播紧急修补程序开发通过 cherry pick 或补丁完成。...以一种允许您的团队根据手工请求将构建版本环境部署生产环境的方式配置 CI。 这些模式相对简单,但提供了支持日常开发操作的强大机制。

    55830
    领券