认识达内从这里开始

随着互联网的不断发展，越来越多的人都在学习java编程开发等达内IT培训课程，今天我们就通过案例分析来简单了解一下，软件开发代码分支策略都有哪些类型。

主干开发

开发持续向主干提交代码，并基于主干进行测试验证;

在主干上修复缺陷，再同步修正的代码到需要的发布分支上;

每次均基于主干，创建指定版本的发布分支;

可享受持续集成、验证、交付带来的好处，消除不必要的分支切换和代码合并工作;

如果有众多成员同时工作在一个主干上，相互间容易干扰、引发代码冲突等问题;

可借助特性切换机制(如部署时的配置、代码中的判断)，来规避不同版本间的差异(如隐藏不成熟的特性，赋予社区版和专业版不同功能)，但容易引发新的问题和复杂性。

GitFlow

开发人员在Feature分支上实现新的特性，并提交代码;

频繁将Feature分支上的代码合并到Develop分支，并做集成测试;

集成Develop分支上的代码到Release分支，完成集成和系统测试;

推送Release分支上的代码到Master分支进行发布;

在Hotfix分支上修复线上缺陷，验证通过后发布补丁，并同步到Master和Develop分支;

始终将Master分支视作整个项目的基线，并在其上对标各个版本的快照;

如果长时间在Feature分支上工作，可能会导致朝Develop分支上合并时产生冲突;

可选择性地省略Develop或Release分支，在Master分支上完成持续集成和发布;

可选择性地省略Hotfix分支，在Feature分支上完成线上问题的修复。

GithubFlow

从主分支创建一个特性分支，用于开发;

在特性分支上完成开发后，提交一个PullRequest(PR)申请向主分支推送代码;

组织相关人员对PR代码进行审查，合并主分支上的代码进行测试和验证;

PR批准后，合并代码到主分支，删除特性分支;

编译、打包主分支上的新代码，部署到生产环境;

该模型频繁合并代码，进行自动化集成、验证和部署，符合CI和DevOps工程学理念;

可持续向主干集成有价值增量，尽早在可运行的完整系统上进行测试验证，符合敏捷开发的精神;

该模型更适合于运营在相同环境下、沿着单线演进的项目，如在线服务;

对于一些在不同客户处、有很多不同版本的产品，以及规模较大的工程或团队，操作会有一定难度。

GitlabFlow

对应GithubFlow中的PullRequest(PR)，存在一个名为MergeRequest(MR)的过程;

在发布侧(图中Master分支以上部分)，增加了Pre-Production和Production分支;

从主分支到Production分支代码的Promotion，需逐层提交MR进行评审和验证;

通常在Master分支上修复缺陷，再逐层Promote到上层产品分支;

需维护集成环境(对应Master分支)、预上线环境(对应Pre-Production分支)和生产环境(对应Production分支)多个环境;

相比GithubFlow，更适合于同时需要维护多个版本的、对外发布的产品;

推荐以单个特性的颗粒度，完成从Feature分支到Master分支的MergeRequest，以方便日后在产品的不同版本编号(如V1.0、V2.0)、不同版本系列(如社区版、专业版)上，进行功能的划分和组合。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。