云效DevOps实践-分支模式

分支模式是我们在进行代码变更时的一种约定，它在版本管理工具（如Git）之上，约定我们在不同分支上的行为，达到提升开发协作效率的目的。

背景
让我们回到软件开发的早期，那时有很多独行的勇士，他们一个人写一个操作系统、一个周末搞一个编辑器。他们把代码上传到FTP上，或通过磁盘分发。这个时期软件开发由一两个人独自完成，不需要版本管理工具，也没有分支模式。

随着通用软件和行业软件的发展，软件的规模越来越大，有些软件需要几千名工程师，经过几年的开发、测试，才能最终发布。大家比较熟悉的windows、office软件，华为等通信设备商开发的2G、3G基础软件是这方面的典型代表。随着大型软件开发的出现，版本管理工具随之出现了，如CVS、Subversion和clearcase。这一阶段通常是集中式的版本控制，分支比较昂贵，大家的提交频率较低，代码集成往往需要专门的配置管理工程师协助解决。软件发布的周期从数周到数年。

之后软件的应用场景越来越广，尤其是互联网应用的快速发展，要求软件的发布周期越来越短。于是，微服务架构被提了出来，单体应用根据领域被拆分成多个服务，每个服务可以独立开发、独立测试、独立部署。这样，很多需求只需要涉及少数的几个应用，在十几人以内的小团队内部就可以完成。互联网应用爆发，加上Git这样的分布式版本管理工具出现，多分支开发变得普遍，高效的开发者经常一天提交十几次。软件发布的的周期缩短到数周乃至数天。

为什么要有分支模式
从前面的背景介绍，大家可能已经发现，分支模式是随着软件协作的需求和版本管理工具的发展而产生的，它的出现，本质上是为了解决两个问题：

冲突
返工
通过避免冲突和减少返工，让开发者关注在需求开发上，提升软件的发布质量和发布效率。

当前，绝大多数软件研发都采用Git为版本管理工具，为了简单起见，之后我们提到分支模式，均特指基于Git的分支策略。

避免冲突
如果多个人同时在同一个应用的同一个分支上开发，那么他们两人的工作很容易产生冲突。这里的冲突不一定是Git提交时的conflict。像测试被其他人破坏，发布需要等待其他人完成，都属于冲突的范畴。简言之，一个需求的开发被其他需求开发活动所干扰，就