分支与合并
实际软件开发中，并行开发有多种场景，也会为这些场景制定对应的分支策略。不论使用哪种分支策略，都是基于某个分支编译（或不需要编译）产生部署包，用这个部署包发布到对应的环境。根据分支是否需要集成，可以简单描述为：
单分支模式：基于一个分支进行代码提交，并最终发布。如特性分支发布、纯主干模式都是这种方式。
分支集成模式：基于多个分支并行开发，然后集成后进行发布。集成时，根据不同的业务场景，又有两种处理方式：
–分支集成后可以灵活退出，这时发布分支通常是使用动态的短分支，发布后发布分支即可删除。
–需要有一个分支展示代码的最新集成状态及结果，如 gitflow 模式，dev 是一个长分支，是代码的最新集成状态。
在分支集成模式下，会有这样一个场景，发布分支（release 分支）的特性组成是动态的。对于增加特性分支（feature 分支）在操作上相对简单，合并新的特性分支到发布分支就可以了。但对于已经集成到发布分支的，可能会由于市场策略调整或甲方的一个变更，延迟发布或取消发布。也可能某个特性分支存在严重问题，需要取消发布。这时候就需要把已经合并到发布分支的特性分支剔除。
使用 Git 命令或代码托管平台可以完成发布分支的创建、合并，但在特性分支需要灵活退出时，需要确定正确的发布分支，若没有工具平台支撑，手工操作繁琐且容易出错。
云效解决方案
云效 Flow 对分支模式提供了强有力的支持：用户只需要关心集成和发布哪些 feature 分支，而对 release 分支创建和管理、分支合并、发布等一系列工作，都可以托付给 Flow 完成。
立即体验：云效流水线Flow
本节内容详细介绍分支模式下，各（类）分支的使用方式。
master 代表最新发布版本
一般情况下， master 分支代表最新发布版本。当需要最新发布版本的内容时，直接取分支末端即可。
不论其他哪类分支，都建议一般从 master 分支创建，并且经常从 master 分支合并，以便跟上“潮流”，减少将来集成时的各种问题，比如代码合并冲突。
每当软件正式发布前，系统会确保它基于 master 最新。
每当软件正式发布后，系统会把相应内容合并回 master，以便让 master 分支始终代表最新发布版本。
一般来说，使用者不要直接“写”东西到master分支。把“写”的工作交给系统适时自动完成。
在各 feature 分支上开发
一条 feature 分支（又称变更分支、开发分支），通常用来承载一个缺陷的修复，或者一个需求（如果不是很大的话）的开发，或者任务分解后一个任务的开发。
一般来讲，基于 master 分支最新版本创建 feature 分支。然后在 feature 分支上开发、测试，直到这个 feature 功能完成，质量 OK，准备好去集成和发布。
release 分支上的集成
release 分支用于集成和发布。基于 master 分支最新版本创建一条 release 分支，然后把想要集成的各条feature分支合并到这条release分支，进行部署和测试工作。
如果有新的 feature 分支要加入本次集成，那就把它也合并进这条 release 分支，然后再次部署并测试。
如果测试发现问题，就到 feature 分支上修复，然后把它再次合并到 release 分支，把修复带到 release 分支。
当然如果一个 feature 的问题太多太大，那干脆就放弃它。也就是说，新建一条 release 分支，把其他 feature 分支都合并过去，唯独不再合并这条 feature 分支。
就像 master 分支一样，release 分支也是由系统自动管理的。使用者不要直接在上面改代码，代码修改请总是在 feature 分支完成。
release 分支上的发布上线
当 release 分支上的质量足够好，本次想上线的功能也都具备之后，就要考虑发布上线的问题啦。如前面讲的，发布上线前，会确保它基于基础分支（常见的如 master ）最新。而发布后会把 release 分支合并回 master，让 master 代表最新发布版本。
以上几节介绍的内容，见下图：
多个环境/流程时
假定要想集成发布上线，要经过日常测试环境上的测试这个流程，还要经过预发环境上的测试这个流程，那么两个流程用一条 release 分支就有些不合适。因为两个流程可能同时在测不同的 feature 分支集合。
分支模式用这个办法避免这个问题：每一个测试环境，也就是每个流程，关联它自己的 release 分支。日常测试、预发测试这两个环境（也就是两个流程），分别关联两条 release 分支。这样就不会相互影响。推而广之，为正式运行环境，也对应一条release分支。也就是说，每个环境都有对应的 release 分支。
当把集成成果从一个环境传递到下一个环境时，就是把一个环境下已合并到一起的 feature 分支，再往另一个环境对应的 release 分支上合并一遍……这么做有点儿笨。系统实际的做法是，基于 master 分支创建另一个环境对应的 release 分支，然后把前一个环境对应的 release 分支合并到新的 release 分支上。
本节介绍的内容，对应下图：
以上就是关于分支模式这种研发模式的原理性介绍，以下我们看一下如何在流水线中使用分支模式。
如何在云效 Flow 中使用分支模式
编排流水线
立即体验：云效流水线Flow
流水线的新建方式与其他流水线相同，当新建流水线时选择了开启分支模式，就会自动创建包含分支管理器的分支模式流水线。
新建流水线。
添加代码源，以使用Codeup为例，选择代码库，选择开启分支模式，然后点击添加。
添加完成后，在流程配置页面可以看到自动添加了第一个阶段分支管理器。在分支管理器中设置基础分支，基础分支默认是 master。基础分支是发布分支的创建来源。发布分支从基础分支创建，然后合并运行分支。分支管理器只能是在第一个阶段配置，且在这个阶段不能配置并行任务。若有多版本发布需求，如 1.0，2.0，这里的基础分支可以设置为 master1.0，master2.0，实现多版本发布的流水线。
运行流水线
流水线配置完成后，就可以开始运行了。
点击保存并运行后，在运行配置弹窗中添加运行分支。
进入添加运行分支对话框，选择运行分支后添加。如需添加多个分支可重复步骤一和二。
运行分支添加完成后，就可以开始运行。在分支管理器中可以查看执行结果及日志。若合并冲突，需要根据提示解决冲突后继续运行。通过流水线源的分支详情或分支管理器的分支详情可以查看创建的 release 分支及运行分支信息。
再次运行时，可以选择继续添加分支或删除已集成分支。
删除已集成分支，执行流水线时将会进行以下操作：
基于分支管理器中设置的基础分支（如 master），创建新的 release 分支。
除了该特性分支外，配置中的其他分支合并到 release 分支。
基于 release 分支的最新内容运行流水线。