代码仓库-分支策略

采用合适的分支策略,可以最大限度的减少构建各个环境代码包能遇到的问题。在一个项目的各个阶段,可以采用不同的分支策略,减少CI/CD可能遇到问题

Git分支策略

1. TrunkBased

在这里插入图片描述

工作方式

TrunkBased (Trunk based Development)模式是持续集成思想所崇尚的工作方式,它由单个主干分支和许多发布分支组成,每个发布分支在特定版本的提交点上从主干创建出来,用来进行上线部署和 Hotfix(补丁)。
由于开人员之间通过约定向被指定为主干的分支提交代码,因此避免分支合并的困扰,保证随时拥有可发布的版本 。“主干”这个词隐喻了树木生长的场景,树木最粗最长的部位是主干,分支从主干分离出来但是长度有限。

缺点

它的缺点比较明显,太多的团队同时工作在主干上,到发布的时候就可能出现灾难(尤其是多版本并行开发的情况)。

弥补措施

弥补的措施是 FeatureToggle(特性切换) 以及频繁的集成和足够的测试覆盖。

使用场景

目前 TrunkBased 模式主要用在不需要同时维护多个历史版本的 SaaS 型项目,特别是经过微服务改造的各种小型服务上。

2. GitFlow

在这里插入图片描述

工作方式

GitFlow 模式是若干模式的集大成者,包含一个主干分支、一个开发分支、许多的特性分支、许多的发布分支和 Hotfix 分支,以及许多繁琐的合并规则。

缺点

但它使用起来并不是很容易,大量的合并冲突和对集成测试不友好也是它被诟病最多的地方。

与TrunkBased的异同

在 TrunkBased 的基础上,增加了个人仓库和 Pull Request 合并代码的操作,与在同一个仓库里增加个人分支的做法类似。GithubFlow 也有演进版本,例如强调了多环境部署和将仓库或分支与环境关联的 GitlabFlow 模式。

使用场景

从实用的意义来说,它更合适分布式团队。

4. AoneFlow

AoneFlow 使用三种分支类型:主干分支、特性分支、发布分支,以及三条基本规则。
规则一,开始工作前,从主干创建特性分支。
在这里插入图片描述
规则二,通过合并特性分支,形成发布分支。
在这里插入图片描述
规则三,发布到线上正式环境后,合并相应的发布分支到主干,在主干添加标签,同时删除该发布分支关联的特性分支。
在这里插入图片描述

SVN分支策略

相关文章
相关标签/搜索