上海市网站建,百度seo排名点击器app,赣州网站建设jxgzg3,下载的网站模板怎么编辑目录
一. Git Flow 分支工作流
1. 分支类型
2. 工作模式
3. 特点与适用场景
4. 总结与思考 二. 基于版本驱动的有主分支工作流
1. 分支类型 2. 工作模式
三. 基于版本驱动的无主分支工作流
1. 分支管理模型
1.1 分支类型
1.2 工作模式
1.3 特点与适用场景
2. 分支…目录
一. Git Flow 分支工作流
1. 分支类型
2. 工作模式
3. 特点与适用场景
4. 总结与思考 二. 基于版本驱动的有主分支工作流
1. 分支类型 2. 工作模式
三. 基于版本驱动的无主分支工作流
1. 分支管理模型
1.1 分支类型
1.2 工作模式
1.3 特点与适用场景
2. 分支开发流程 本文系统介绍了三种Git分支工作流模型1. GitFlow工作流结构化分支模型包含主分支(master)、开发分支(develop)及多种辅助分支适用于多版本维护的项目2. 有主分支工作流基于master主分支与develop开发分支的简化版本适合常规版本发布需求3. 无主分支工作流完全由版本迭代驱动的简化模型仅使用develop分支跟随版本轮转适合周期性迭代项目。 一. Git Flow 分支工作流 A successful Git branching modelA successful Git branching model » nvie.com 图 1.1 Git Flow 工作流
图 1.2 Breaking Change 历史版本维护
Git Flow 是一种严格结构化、围绕版本发布为核心的 Git 工作流模型需要注意这与持续发布的项目模式是不同的其目标是基于时间线不断产出新版本来驱动系统演进。该分支管理模型的核心在于使用不同功能、生命周期明确的分支来严格分离开发的不同阶段支持多版本并行、历史版本维护等复杂场景衍生出多种简化版本的工作流模型。
1. 分支类型
Git Flow 工作流中的分支主要由核心分支和辅助分支两种类型组成每种分支的角色与职责介绍如下
核心分支核心分支都属于长期分支应在项目进行阶段持续存在 主分支master/main主分支上的每个节点都表示生产环境发布的稳定正式版本并使用版本号Tag标记每个提交。主分支不允许直接进行代码修改只能接受来自hotfix分支和release分支的合入提交开发分支develop开发分支也称为集成分支可以看作是主分支的超集包含已发布功能、计划发布功能用于进行持续开发和功能合并当开发分支迭代达到发布条件时应及时创建版本发布分支release。开发分支只能接受来自feature分支、hotfix分支和release分支的合入提交支持分支support支持分支用于在主分支发生破坏性版本提交breaking change时接替主分支的角色继续维护对应历史并行版本该分支只能接受来自于feature分支的合入提交 辅助分支辅助分支都属于短期分支可在分支使用完成后废弃 功能分支feature功能分支是用于完成特定的功能或开发任务而从开发分支或支持分支临时创建的分支该分支通常只存在于开发人员的本地仓库除非该功能分支需要多人协同开发发布分支release发布分支是在开发分支达到版本发布条件时新功能积累完成或到达发布周期为新版本预发布而创建的隔离分支使得开发分支可以继续接受后续版本计划的功能提交。发布分支创建后通常将不再添加新功能仅用于进行版本发布前的集成测试、缺陷修复和生成发布文档等注意该分支在准备就绪后除了合并回主分支发布还必须合并回开发分支以同步变更补丁分支hotfix补丁分支非常短暂仅用于紧急修复生产环境中主分支上产生的线上问题或安全漏洞该分支在修复完成后必须立即合并回主分支以及开发分支
2. 工作模式
日常开发场景develop - feature - develop - release - master/develop历史维护场景master - support - feature - support紧急修复场景master - hotfix - master/develop紧急需求场景develop - release - master/develop
3. 特点与适用场景
图 1.3 Git Flow VS GitHub Flow
严格结构化管理明确的多分支定义工作流程结构化能够清晰分离不同开发阶段支持多开发活动并行进行。适用于大型团队与复杂项目的协作与管理降低发布阻塞风险强版本控制发布节点清晰可溯、版本历史明确支持多个版本并行维护。适用于有明确版本发布计划、发布周期较长或需要维护历史版本的项目复杂且不够灵活复杂程度较高且发布周期较长存在“合并地狱”问题不适用于需要频繁发布和持续部署、或版本概念弱相关的项目及团队这种场景可以考虑GitHub Flow或GitLab Flow工作模型
4. 总结与思考 图1.4 By Vincent Driessen 这个模型是在2010年构思的到现在已经10多年了也就是Git本身诞生不久之后。在这10年里Git Flow 在许多软件团队中变得非常流行以至于人们开始将其视为某种标准但不幸的是它也被视为教条或灵丹妙药。如果你的团队正在进行软件的持续交付我建议采用更简单的工作流程如GitHub Flow而不是试图将Git Flow强行塞进你的团队。然而如果你正在构建明确版本化的软件或者你需要同时支持软件的多个版本那么Git Flow可能仍然适合你的团队。总之永远记住灵丹妙药并不永远存在。 -- Vincent Driessen 二. 基于版本驱动的有主分支工作流
图2.1 Git 分支工作流
1. 分支类型
master分支master主分支长期存在其代码总是稳定可靠的并可随时发布。注意不能在该分支上直接修改代码所有具备上线条件的版本都需要合并到master分支develop分支develop分支长期存在该分支将从master主分支跟随版本创建用于当前版本的开发使用。注意当版本具备上线条件时需要合并回master分支以及后续版本的develop分支hotfix分支hotfix分支短期存在该分支将从master主分支创建用于线上版本问题的紧急修复注意fix完成后需合并回master分支、develop分支 2. 工作模式
版本开发 软件开发工程师根据版本从master主分支最新节点上创建版本开发分支develop并在develop分支上完成当前版本所有功能需求的开发当具备发布条件时需强制检测master主分支的代码改动并合入当前版本分支推送版本转测问题修复当需要紧急修复线上问题时由开发工程师从master主分支节点上创建修复分支hotfix并在修复完成后直接合入主分支注意主分支master上的改动需合并到后续版本的develop分支以完成同步
三. 基于版本驱动的无主分支工作流
图3.1 版本迭代计划示意图
假设系统的版本迭代基于四周版本迭代计划驱动即以两周为一个完整的开发周期、以四周为一个完整的上线周期在版本迭代周期中由开发版本、测试版本和上线版本三个版本串行轮转。开发人员在版本迭代周期中的职责包括
开发版本负责迭代功能与需求的设计、评审、实现与自测保证基本功能逻辑能够覆盖大部分场景、核心流程不出问题冒烟通过测试版本负责解决测试版本中产生的缺陷问题、以及体验与优化等问题保证版本功能逻辑的完善、尽可能满足用户需求上线版本负责上线版本巡检、以及线上问题的处理保证线上用户的正常使用、避免产生客诉问题
图3.2 Git 分支工作流
1. 分支类型
系统的云端分支类型只有develop开发分支该分支始终跟随版本创建当前版本develop分支将从上个版本develop分支的最新节点创建一般为转测节点并长期存在用于承载当前版本的开发、转测、修复与上线发布等全生命周期的工作。
2. 工作模式
1分支创建分支跟随版本从上个develop分支的最新节点创建开发分支的命名通常由分支前缀和版本标识两部分组成并通过_下划线连接如“分支前缀_版本标识”具体包含正常迭代和紧急支持两种开发场景
正常迭代版本版本号使用偶数迭代。正常迭代版本是指按照版本迭代计划正常驱动的需求或版本比如 dev_1.1.0、dev_1.1.2 ...紧急支持版本版本号使用奇数迭代。紧急支持版本是指在系统迭代计划三个版本串行轮转过程中紧急插入或需紧急上线的需求或问题需单独转测或无法跟随任何正常迭代版本上线的特殊情况由于该模式不维护历史版本也不支持多版本并行因此针对紧急需求将启用奇数版本号比如 dev_1.1.1、dev_1.1.3 ...
2开发与提交开发人员基于当前版本创建的develop分支在本地checkout out检出并进行开发和提交支持多人协同开发当代码开发完成后需及时推送及合入远程develop分支并手动解决提交过程中产生的代码冲突
3转测与发布当版本功能全部开发完成并自测通过、具备转测条件时由开发人员在当前版本develop分支的最新节点上打Tag发布转测版本同步到测试人员并在该develop分支上持续跟踪并修复缺陷问题直到转测过程完全通过当版本具备上线条件时需要将该版本develop分支合并回后续版本的develop分支以保证代码同步版本推送前需强制进行分支合并检查是否合并了之前分支的最新代码
图3.3 Git 分支开发流程
3. 特点与适用场景
强版本控制由版本迭代计划驱动周期性集成与迭代严格按照时间周期运行通常为三个版本串行轮转无主分支无主分支概念分支始终跟随版本创建简单明确便于维护、支持多人协同开发历史连续性不维护历史版本也不支持多版本并行版本分支之间串行轮转具有连续性、继承性不够灵活分支的管理与版本绑定版本又跟时间强相关需要单独特殊处理处理紧急需求或问题在灵活性上存在不足
