分支开发、主干发布最佳实践_云效(Apsara Devops)-阿里云帮助中心

1. 场景介绍

实际软件开发中，并行开发有多种场景，也会为这些场景制定对应的分支策略。不论使用哪种分支策略，都是基于某个分支编译（或不需要编译）产生部署包，用这个部署包发布到对应的环境。

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 分支完成。