之前分享过《版本分支管理标准 - Git Flow》,不过在实际使用过程中, 因为其有一定的复杂度,使用起来较为繁琐,所以一些人员较少的团队并不会使用这个方案。

在这基础上,一些新的分支管理标准被提出。这里转发一下这个标准:《Trunk Based Development 主干开发模型》。


Preface

在之前的博文中我们介绍了 Git Flow 分支模型,正如文中所说,Git Flow 偏向于控制管理,使用了较多的分支,流程颇为复杂。大量的团队在实践过程中也遇到了颇多问题,其中大部分来自长期存在的分支。随着软件开发模型的演进,GitHub Flow、Trunk Based Development 等模型也应运而生,也已被 Google、Facebook、TW 等企业实践。本文主要介绍 TBD 模型。

Git Flow的问题

  • 合并冲突,合并冲突在使用 Git Flow 是非常常见的。原因很简单:如果你有多个并行功能分支,他们长时间存在,那么很可能代码库的相同部分在两个功能分支中被分别更改。合并冲突不仅对于需要手动解决的开发人员来说是令人沮丧的,也增加了在代码中破坏某些功能的风险,因为当你不得不决定使用哪个版本代码时,很容易犯错。
  • 功能分离,在合并到同一个分支之前,你不能测试两个功能的组合。当你在单独的分支中开发几天甚至几周的功能时,当合并回主分支后,可能也会发生两个功能的相互作用影响了你的代码。
  • 并没有做到持续交付,在 Git Flow 分支模型下,发布是非常有计划的,一个 feature 必须要经过一系列步骤才能到达生产环境,在时间上平均一个 feature 都要等待 两周时间才能长线,这样的等待并非是需求上的“按计划发布”,而是从技术上就造成了发布瓶颈,显然难以达到持续交付的要求。
  • 与持续集成相悖,你会发现,在坚持持续集成实践的情况下,feature 分支是一件非常矛盾的事情。持续集成鼓励更加频繁的代码集成和交互,让冲突越早解决越好。feature 分支的代码隔离策略却在尽可能推迟代码的集成。

GitHub Flow

GitHub Flow 是一个更轻量级的软件开发模型,示意图如下。它摒弃了 Git Flow 中繁杂的分支, 只保留一个主分支 master 。开发新功能时从 master 分支上拉取 feature 分支,开发完成后发起 Pull-Request ,小组内进行评审和反馈,此时也进行 Code Review 。测试通过后合并回主分支。

相比于 Git Flow,这种方式因为省去了一些分支而降低了复杂度,同时也更符合持续集成的思想,以一张故事卡为集成的最小单位,相对来说集成的周期短,反馈的速度也快,能够及早的遇到问题并及早解决。

顺着持续集成的思想,如果我们把 GitHub Flow 分支模型做得再极致一点,我们不要 feature 分支,或者把 feature 分支只留在本地;不需要使用 Pull-Request 而是直接 Push 到远程 master 分支,我们就做到了 Trunk based Development。

TBD

Trunk based Development,又叫 主干开发 ,是一套代码分支管理策略,开发人员之间通过约定向被指定为 主干 的分支提交代码,以此抵抗因为长期存在的多分支导致的开发压力。此举可 避免分支合并的困扰,保证随时拥有可发布的版本 。“主干”这个词隐喻了树木生长的场景,树木最粗最长的部位是主干,分支从主干分离出来但是长度有限。

使用主干开发后,我们的代码库原则上就只能有一个 Trunk 分支即 master 分支了,所有新功能的提交也都提交到 master 分支上,保证每次提交后 master 分支都是可随时发布的状态。没有了分支的代码隔离,测试和解决冲突都变得简单,持续集成也变得稳定了许多,但也有如下几个问题:

  • 如何避免发布引入未完成 Feature,答案是使用 Feature Toggle 。在代码库里加一个特性开关来随时打开和关闭新特性是最容易想到的也是最容易被质疑的解决方案。Feature Toggle 是有成本的,不管是在加 Toggle 时的代码设计,还是在移除 Toggle 时的人力成本和风险,都是需要和它带来的价值进行衡量的。
  • 如何进行线上 Bug Fix,答案是在发布时打上 Release Tag,一旦发现这个版本有问题,如果此时 master 分支还没有其他提交,那可以直接在 master 分支上 Hot Fix 然后合并至 release 分支;如果 master 分支已经有了提交就需要做以下三件事:
    • 从 Release Tag 创建发布分支。
    • 在 master 上做 Fix Bug 提交。
    • 将 Fix Bug 提交 Cherry Pick 到 release 分支。
    • 为 release 分支打上新的 Tag 并做一次发布。

说明

  • 主干开发是助力实现 持续集成持续交付 的关键因素。开发团队的成员一天多次地将代码提交到主干分支,满足了持续交付的必要条件。团队的工作在 24 小时内就可以被整合,这保证了代码版本随时处于可发布状态,使得持续交付成为可能。
  • 你可以选择直接向主干分支提交代码的方式(适用于小团队)或者采用 Pull-Request 的方式,只要保证特性分支不能长期存在,并且产品是独立存在的。
  • 根据团队规模和提交频率, 特性分支可用于合并到主干分支前的代码审查和持续集成 。这些特性分支可以让开发人员在代码合并到主干分支之前进行持续审查,而对于较小规模的团队,则可以直接向主干分支提交。
  • 根据预期的发布频率,你的团队或许需要实时从主干分支创建 发布分支 以确保发布版本不会有新的提交,这些分支应该在发布完成后一段时间内删除。另一方面,你的团队也可以选择从主干分支发布而不需要发布分支,并采用“ 修复前进(fix forward) ”的策略进行 bug fix,这种发布策略适用于高吞吐量的团队(high-throughput teams)。

References

以上所述就是小编给大家介绍的《Trunk Based Development 主干开发模型》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

版本分支管理标准 - Trunk Based Development 主干开发模型的更多相关文章

  1. 版本分支管理标准 - Git Flow

    最近好多开发人员在问如何使用 GIT 进行代码的版本管理. 这里转发一个标准的分支版本控制图. 相关的详细介绍,可以看: <引入git flow分支管理> <非常清晰明了的GIT版本 ...

  2. 一、VIP课程:互联网工程专题 02-Git服务搭建与版本分支管理

    第二课:搭建企业私有Git服务.docx 课程概要: GIT远程通信协议详解 基于gogs 搭建WEB管理服务 一.GIT服务器搭建方式 上一节课我们讲过GIT是一个分布式版本管理系统,既然是分布那么 ...

  3. Git工程开发实践(四)——Git分支管理策略

    A successful Git branching model https://nvie.com/posts/a-successful-git-branching-model/ Git工程开发实践( ...

  4. Git 分支管理策略汇总

    原文链接: Git 分支管理策略 最近,团队新入职了一些小伙伴,在开发过程中,他们问我 Git 分支是如何管理的,以及应该怎么提交代码? 我大概说了一些规则,但仔细想来,好像也并没有形成一个清晰规范的 ...

  5. Git 分支管理详解

    大纲: 1.前言 2.创建分支 3.切换分支 4.合并分支(快速合并) 5.删除分支 6.分支合并冲突 7.合并分支(普通合并) 8.分支管理策略 9.团队多人开发协作 10.总结 注,测试机 Cen ...

  6. 项目版本与分支管理之阿里AoneFlow模式分析

    前言 在我前期的项目管理的经验中,一个项目需要维护多个产品及多个版本,这给版本与分支的管理增加了难度.前期没有重视,使得分支太多太乱,版本也没记录好,引发了很多的问题.在多种分支与版本的管理模式下,最 ...

  7. git学习------>Git 分支管理最佳实践

    ps:本文转载于 : https://www.ibm.com/developerworks/cn/java/j-lo-git-mange/index.html Git 是目前最流行的源代码管理工具.大 ...

  8. SVN 分支管理

    平时在工作中使用 SVN 只是限于 commit,update 这样的操作,至多再 reslove 解决一下冲突,没有用过分支管理.开发过程中一般都是一个功能开发完成之后整体进行提交,而最近在项目中有 ...

  9. Atitit 版本管理----分支管理

    Atitit 版本管理----分支管理 版本管理系统"(Version Control System Branch/tag在一个功能选项中,在使用中很容易产生混淆. 分支(Branch)管理 ...

随机推荐

  1. 练手WPF(三)——扫雷小游戏的简易实现(中)

    八.随机布雷 /// <summary> /// 随机布地雷 /// </summary> /// <param name="mineNum"> ...

  2. Java生鲜电商平台-积分,优惠券,会员折扣,签到、预售、拼团、砍价、秒杀及抽奖等促销模块架构设计

    Java生鲜电商平台-积分,优惠券,会员折扣,签到.预售.拼团.砍价.秒杀及抽奖等促销模块架构设计 说明:本标题列举了所有目前社会上常见的促销方案,目前贴出实际的业务运营手段以及架构设计,包括业务说明 ...

  3. 【转】Linux上安装rz和sz命令

    简介 lrzsz 官网入口:http://freecode.com/projects/lrzsz/ lrzsz是一个unix通信套件提供的X,Y,和ZModem文件传输协议 windows 需要向ce ...

  4. Android Studio 3.5+ 使用androidx的recyclerView

    一 File->project structure->Dependencies: 点击All Dependencies处的加号,选择Library Dependency: 在step1处输 ...

  5. Linux命令: ps

    STAT 进程状态 S-睡眠 s-进程是会话向导进程 N拥有比普通优先级更低的 R-正在运行 D-短期等待 Z-僵尸进程 T被跟踪或者被停止 STATED 进程启动时间 TIME  进程使用CPU时间 ...

  6. Mac Kafka 环境搭建

    1.安装java 注意:kafka 截止发稿日兼容最高版本为1.8 千万不要安装 更高版本 ,我就是安装了12的发现不支持卸载了重装的

  7. Nginx03(实现负载均衡)

    一.负载均衡的作用 1.转发功能 按照一定的算法[权重.轮询.Ip_Hash],将客户端请求转发到不同应用服务器上,减轻单个服务器压力,提高系统并发量. 2.故障移除 通过心跳检测的方式,判断应用服务 ...

  8. 3-3 groupby操作

    Pandas章节应用的数据可以在以下链接下载:  https://files.cnblogs.com/files/AI-robort/Titanic_Data-master.zip .caret, . ...

  9. 001-OpenStack-基础环境

    OpenStack-基础环境 1.实验描述 通过搭建 OpenStack 的 ocata 版,来学习虚拟化技术 2.实验环境 [你可能需要][CentOS 7 搭建模板机]点我快速打开文章 [你可能需 ...

  10. PAT 乙级真题 1003 我要通过!题解

    1003 我要通过! (20 分) “答案正确”是自动判题系统给出的最令人欢喜的回复.本题属于 PAT 的“答案正确”大派送 —— 只要读入的字符串满足下列条件,系统就输出“答案正确”,否则输出“答案 ...