分支模式

分支模式是云效支持的三种研发模式的一种。每种研发模式，不仅意味着其中各（类）分支的使用方式，也意味着云效能够向用户提供的相应支持，分支模式也不例外。事实上，云效对分支模式提供了强有力的支持：用户可以只需要关心集成和发布哪些feature分支，而对release分支创建和管理、分支间合并等一系列工作，可以托付给云效系统完成。

本文详细介绍分支模式下，各（类）分支的使用方式。关于云效提供的相应支持，详情请阅读分支模式下的流水线。

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分支上。

本节介绍的内容，对应下图：

小结

以上就是关于分支模式这种研发模式的原理性介绍。更多细节在分支模式下的流水线中讲解。