一、主流的分支模式

TBD（主干开发模式）
Git-Flow
GitHub-Flow
GitLab-Flow

二、TBD主干开发模式

1.定义

即所有开发者，仅在一个开发分支（即主干）上进行协作开发的模式，这种模式下，不允许新建任何长期存在的开发分支，有且仅保留主干分支进行开发协作。
因为没有长期分离的其他开发分支，任何代码变更持续地更新到主干上，在一定程度上避免了 merge 代码带来的困扰。在 TBD 模式下，所有的修改都是在主干上，哪怕是缺陷的修改也是，修改完缺陷后，再 cherry pick 到发布分支上。

2.特点

（1）有且仅有一个开发分支，即主干分支。
（2）所有改动都发生在主干分支。
（3）发布可以从主干拉发布分支。
（4）主干上进行的修复需要根据缺陷的修复策略，确定是否 cherry pick 到对应版本的发布分支。

3.图例

在这里插入图片描述

三、Git-Flow

1.定义

Git-Flow 是为了解决多个不同特性之间并行开发需要的一种工作方式。当开始一个特性的开发工作的时候，从主干上拉出一个特性分支，所有的关于该特性的开发工作都发生在这个特性分支上，当完成该特性的工作之后，再把特性分支合并回代码主路径上，并准备发布。

2.Git-Flow 有以下几种分支：

feature 分支：开发者进行功能开发的分支。
develop 分支：对开发的功能进行集成的分支。
release 分支：负责版本发布的分支。
hotfix 分支：对线上缺陷进行修改工作的分支。
master：保存最新已发布版本基线的分支。

3.其中Hotfix 的流程如下：

（1）如果发布之后，发现了缺陷，基于 master 拉出一个 hotfix 分支。
在 hotfix 对问题进行修改及验证。
（2）问题的修复合并到 develop 和 master 上。
（3）删除 hotfix 分支。

4.相关图示

在这里插入图片描述

四、GitHub-Flow

1.与Git-Flow对比

（1）GitHub-Flow没有 Git-Flow 中所介绍的 release 分支。对于 GitHub-Flow 来说，发布应该是持续地，当一个版本准备好，它就可以被部署。
（2）在 hotfix 上的处理，GitHub-Flow 认为hotfix 与那些小的特性修改没有任何区别，它的处理方式也应该与之相似。

2.对比Git-Flow特点

相比 Git-Flow 来说，有个显而易见的好处——简单。另一个好处就是持续部署的要求，尽可能快速地发现 master 分支的问题，并能通过 rollback 等机制，快速恢复。将所有内容合到 master 分支中，并经常部署，意味着你可以最小化未发布的代码量，这也是精益开发和持续交付所倡导的最佳实践。部署原本是一件很繁琐的事情，但是因为要频繁做，我们就容易把这样一件事情做简单，以达到持续交付的目的。
虽然 GitHub-Flow 简化了 Git-Flow 的分支模式，但是对于部署、环境、以及发布，该分支模式仍然存在许多未回答的问题，所以，我们希望通过 GitLab-Flow 来为这些问题提供更多的参考。

3.图例

在这里插入图片描述

五、GitLab-Flow

1.与GitHub-Flow对比

GitLab-Flow 相比于 GitHub-Flow 来说，在开发侧的区别不大，只是将pull request改成了 merge request，而 merge request 的用法与 pull request 类似，都可以做为代码评审、获取反馈意见的一种沟通方式。
最大的区别体现在发布侧，即引入了对应生产环境的 production 分支和对应预发环境的pre-production 分支（如果有预发环境的话）。这样，master 分支反映的是部署在集成环境上的代码，pre-production 分支反映的是部署在预发环境的代码，production 分支反映的最新部署在生产环境的代码。