首页
学习
活动
专区
工具
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 分支管理策略 分支模型与主干开发

85010

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

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

5.3K30

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

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

80130

持续交付之基于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

58120

持续交付之基于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.2K30

架构师分享 高效团队的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 版本规则 版本号.次版本号 构建时,自动增加修订号

4K10

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

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

34520

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

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

36120

高效团队的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 版本规则 版本号.次版本号 构建时,自动增加修订号

4K31

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

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

2K62

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

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

41720

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

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

84030

团队如何选择合适的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完成。

72800

关于制定 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 分支就是功能分支,建议是一个模块就拉一条分支。但是,在实际开发中还是要看情况。

1K141

团队如何选择合适的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完成。

71660

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

前言 高效的持续交付体系,必定需要一个合适的代码分支策略。采用不同的代码分支策略,意味着实施不同的代码集成与发布流程,这会影响整个研发团队每日的协作方式,因此研发团队通常需要很认真地选择自己的策略。...Git Flow 模型 主要包括: 分支:master,稳定版本代码分支,对外可以随时编译发布分支,不允许直接 Push 代码,只能请求合并(pull request),且只接受 hotfix、release...分支:随现场使用情况而定,可以打临时版本或补丁;由分支替换而来,修复完后合并到分支、开发分支; 预览分支:版本发布分支,用于迭代版本发布。...重流程,使用起来并不是很容易,发布分支拉出后,直到合回主干,若有特性修改或 Hotfix 需要维护多处 CherryPick(选择部分变更集合并到其他分支) 合并; 集成时间滞后:特性分支在功能完成前,...对于持续交付而言,最理想的情况就是,每一次提交都能经历一系列的自动化环境并部署生产环境上面,而这种模式距离这个目标就更近了一点。

1.9K20

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

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

52230

如何正确使用Git Flow

我们已经SVN 切换到Git很多年了,现在几乎所有的项目都在使用Github管理, 本篇文章讲一下为什么使用Git, 以及如何在团队中正确使用。...由于很容易创建新分支分支多了如何管理,时间久了,如何知道每个分支是干什么的? 哪些分支已经合并回了主干? 如何进行Release的管理?...Git Flow常用的分支 Production 分支 也就是我们经常使用的Master分支,这个分支最近发布生产环境的代码,最近发布的Release, 这个分支只能从其他分支合并,不能在这个分支直接修改...Develop 分支 这个分支是我们是我们的开发分支,包含所有要发布下一个Release的代码,这个主要合并与其他分支,比如Feature分支 Feature 分支 这个分支主要是用来开发一个新的功能...同时,其它开发人员可以基于开发新的Feature (记住:一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支) 发布Release分支时,合并ReleaseMaster

2.2K40
领券