小明的研发团队要公布一个版本，这个版本蕴含了多个性能个性，每个不同的个性之间有较强的独立性。不同的个性由不同的开发人员或开发小组分工实现。
他们在不同的个性分支上开发，彼此互相独立、互不影响。
一个个性开发实现后就提交测试，这个过程不影响其余个性的失常开发，全副已实现的个性全副合并进行测试和公布。在提交测试，集成合并时碰到了这样的问题：
- 对于某个公共模块的批改呈现了合并抵触
- 因为一个个性分支的集成，导致整个版本集成失败
版本公布工夫在即，为不影响整体停顿，须要疾速拆散影响了整个集成的那个个性分支。
如果你是小明，这时你会怎么做？
小明的研发团队又要公布一个版本，整个版本有 A、B、C、D 四个性能个性一起合并集成，别离在分支 A、B、C、D 上开发。邻近公布前，市场侧告诉因为某种原因性能个性 B 不能公布，也就是这次公布须要剔除分支 B。依照严格的集成公布策略，A、C、D 这 3 个个性分支须要从新构建，别离再通过集成测试、预发验证，而后到生产公布。然而，这样做是有老本的。
如果你是小明，在效率和品质之间你会怎么选？
这两个情景遇到的问题，在多分支并行开发集成公布中很常见，如何疾速、灵便、高效又实用地解决这类问题，成为泛滥小明的刚需。
阿里巴巴团体外部经验并仍在经验着大量多分支集成公布的实际，这些实际被提炼成了一套阿里的分支策略，造成了阿里分支模式，并通过公共云产品云效 Flow 对外部研发用户输入。
当应用云效 Flow 分支模式时，小明的两个场景问题将能够失去灵便高效地解决。
场景一：如何疾速拆散影响整个集成的那个个性分支
小明能够间接在再次运行分支时，删除已集成分支，执行流水线时将会主动进行以下操作：
- 基于分支管理器中设置的根底分支（如 master），创立新的 release 分支
- 除了该个性分支外的其余在云效配置中的其余分支合并到 release 分支
- 基于 release 分支的最新内容运行流水线
场景二：公布在即需要被砍，如何均衡效率和品质？
小明发现云效分支能够按环境 / 流程，自在地集成，思考到本次上线的工夫对后续我的项目进度十分要害，小明抉择了跳过两头的测试阶段、预发阶段间接部署到正式环境，为了最大水平防止品质危险，小明还应用了云效 Flow 的公布前人工审核卡点能力，最终变更没有耽搁失常发版，也未呈现任何危险。
云效 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 分支上合并一遍……这么做有点儿笨。对于人工解决这是一个反复操作的过程，云效会帮你主动实现这一系列反复的操作。
对应下图：
以上就是对于分支模式这种研发模式的原理性介绍，以下咱们具体看一下如何在云效流水线中应用分支模式。
云效 Flow 分支模式实际
编排流水线
流水线的新建形式其余流水线雷同，当新建流水线时抉择了「开启分支模式」，就会主动创立蕴含【分支管理器】的分支模式流水线。
1、新建流水线
2、增加代码源，以应用「云效 Codeup」为例，抉择代码库，抉择「开启分支模式」，而后点击「增加」
3、增加实现后，在「流程配置」页面能够看到第一个阶段「分支管理器」。在分支管理器中设置根底分支，根底分支默认是 master。根底分支是公布分支的创立起源。公布分支从根底分支创立，而后合并运行分支。「分支管理器」只能是在第一个阶段配置，且在这个阶段不能配置并行任务。
若有多版本公布需要，如 1.0，2.0，这里的根底分支能够设置为 master1.0，master2.0，实现多版本公布的流水线。
运行流水线
流水线配置实现后，就能够开始运行了。
1、在运行配置中，增加运行分支。
2、进入增加运行分支对话框，抉择运行分支。若在代码源抉择的其余代码库，这里输出运行分支。
能够增加多个分支。
3、运行分支增加实现后，就能够开始运行。在「分支管理器」卡片中能够查看执行后果及日志。若合并抵触，须要依据提醒解决抵触后持续运行。
通过「源」的「查看分支」或「分支管理器」卡片的「分支详情」能够查看创立的 release 分支及运行分支信息。
4、再次运行时，能够抉择持续增加分支或删除已集成分支。
删除已集成分支，执行流水线时将会主动进行以下操作：
基于分支管理器中设置的根底分支（如 master），创立新的 release 分支
除了该个性分支外的其余在云效配置中的其余分支合并到 release 分支
基于 release 分支的最新内容运行流水线
小结
简略来说，Flow 分支模式能够自在地组合个性分支，与各自环境的公布分支做集成。
灵便的个性分支:
分支能够自在地灵便组合。抉择任意一个或多个分支进行组合集成。
分支能够灵便地退出，将某个不须要的或有烦扰的分支踢出以后集成 / 环境。
分支能够灵便地退出，将某个须要减少的分支增加到进去。
分支能够按环境 / 流程，自在地集成，能够跳过两头的测试阶段、预发阶段间接部署到正式环境，这个在紧急修复问题时效率较高。
灵便的个性分支当然也存在着问题，因为能够跳过两头的集成环境 / 流程，也就带来了未通过验证的代码公布上线的可能性，这时能够思考应用云效 Flow 公布前人工卡点的能力，让公布多一层品质保障。
分支策略的抉择没有相对的正确和谬误之分，要害是与我的项目布局、公布节奏相匹配，在理论开发我的项目中找到一个能够兼顾效率、品质、简略实用的抉择。
点击下方链接立刻体验云效流水线 Fiow。
https://www.aliyun.com/produc…