网站备案怎么做超链接,个人网站建设计划表,中国建设部官方网站资格证查询,网站宣传推广平台图解六种分支管理模型 任何一家公司乃至于一个小组织#xff0c;只要有写代码的地方#xff0c;就有代码版本管理的主场#xff0c;初入职场#xff0c;总会遇到第一个拦路虎 git 管理流程#xff0c;但是每一个企业似乎都有自己的 git 管理流程#xff0c;倘若我们能掌握… 图解六种分支管理模型
任何一家公司乃至于一个小组织只要有写代码的地方就有代码版本管理的主场初入职场总会遇到第一个拦路虎 git 管理流程但是每一个企业似乎都有自己的 git 管理流程倘若我们能掌握常用的 git 分支管理模型那么无论碰到什么样的 git 管理流程只不过都是这些管理模型的衍生与简化而已。
1.Git Flow
著名大佬 Vincent Driessen 在《A successful Git branching model》一文提出了影响深远的 git 代码管理模型现如今依然许多中大型企业在沿用下面是他提出的流程图 优点分支管理严格代码合并清晰适合于中大型团队应用。 缺点分支流程过多反而也是一种缺点。
2.GitHub Flow
GitHub 于 2011 2011 2011 年创建遵循以下 6 6 6 条原则
master 分支永远是随时可部署发布的。需求新增基于 master 分支并创建一个语义化分支。定期推送本地分支到远端。合并到 master 需要提 PR。PR 一旦经过 code review 无误后即可合并到 master。master 一旦接收到合并请求即可立即部署发布。
其大概的流程图如下 优点分支足够简单且符合人类思维逻辑适用于持续发布场景。 缺点针对多版本产品线则不适用。
3.GitLab Flow
GitLab 在 2014 2014 2014 年提出 11 11 11 条最佳实践其相对 GitHub 增加了环境分支且代码必须由上游master向下游staging发展并且针对持续发布和版本发布都提出了相应的准则下面是其大致流程图 优点git 提交历史更加清晰、简洁与易读。 缺点对开发人员的能力提出了更高的要求当存在多产品线时和 Git Flow 相比平分秋色。
4.TrunkBased
研发团队只在 master 分支进行功能开发当达到发布的条件时直接迁出一个只读分支发布只读分支顾名思义就是不接收任何新代码合并以及在只读分支上进行修改当研发人员相对较多时则可以使用 可扩展版本增加了功能分支但是功能分支不超过两三天则必须要合并到 master 分支其大致的流程图如下 优点简单清晰单兵作战最佳选择适合维护后期超稳定的项目。 缺点不适用多版本共存的项目。
5.OneFlow
Adam Ruka 于 2017 年提出可以简单的理解为 Git Flow 的简化版本除了 develop 开发分支和最新发布 master 分支其余皆是临时分支一旦开发完成即可删除临时分支其中具体细则可查看这里下面是其大致流程图 优点单一版本首选git 提交历史简介清晰易读。 缺点不适合持续交付或持续部署的项目也不适用多版本共存的项目。
6.AoneFlow
由阿里巴巴技术专家林帆基于 TrunkBased 和 GitFlow 提出的一种新改进其主要分为三种分支类型主干分支、特性分支 以及 发布分支并且提出了三个基本准则
主干创建特性分支且不允许合并回主干分支。合并特性分支形成发布分支。发布到线上正式环境后合并相应的发布分支到主干在主干添加标签同时删除该发布分支关联的特性分支。
下面是其大致的流程图 优点灵活易用通过组合生成分支往往可以实现多种高级玩法。 缺点复杂度稍高如果没有配套的工具规范往往会出现 无效分支 的出现。
7.总结
