svn合并分支到主干_谈谈代码分支管理

一、前言

从2019年上半年云音乐的客户端团队开始迁移到双周迭代后，随之而来的是我们需要重新调整代码分支的管理方法，来应对开发流程的变更。

双周迭代顾名思义一周开发一周测试，目的就是为了快速交付。纵观整个开发流程，我们需要在两周内完成：需求交互评审-技术方案设计-开发测试-CodeReview-持续集成-灰度发布-全量发布等一连串工作，并且把每个节点的时间都固定下来，节奏感对于开发来说特别重要，让大家明确每个时间点应该做什么，对于简化管理和提高效率尤为重要。那新的代码分支管理如何适应这种节奏呢？

二、先谈谈现状

业内有很多的分支管理方法，包括著名的GitFlow、TBD以及从他们衍生出来的版本。

1、GitFlow

GitFlow设计非常全面，考虑到了实际开发过程中的各种问题，都能稳定应对，是非常适合大型项目的代码管理。他的主要理念包括2个主干分支——Master和Develop，1个发布分支——Release，若干个开发分支——Feature，以及HotFix分支。整体实施流程略微复杂，对持续集成不太友好，下面是典型的GitFlow模型：

典型的GitFlow模型

GitFlow在实践中有几个问题：

• 因为大家都在自己的Feature分支上面开发，特别是对于长期的Feature分支会可能存在严重的合并冲突问题，需要花费大量的时间解决；
• 同样是基于第一条，导致Feature分支之间相互隔离，以至于CI/CD困难，单个功能可能没有问题，但合并以后是否也没问题谁也无法保证。

2、TBD

Trunk Based Development早在svn时代就已经流行，是种比较简单的分支管理模型，他只有一个主干分支，每个人写完代码自测通过后就往主干上面Push，要发布的时候就拉个Release分支，对持续集成友好。

典型的TBD模型

TBD也存在几个问题：

• 如果临上线前发现有问题，剔除代码比较困难；
• 即使没有需求变更要下掉代码，有些提交如果未能达到上线标准，需要加Feature Toggle来控制打开关闭。这是一个需要平衡的事情，往往会增加一定开发成本和风险。

3、AoneFlow

这是一篇阿里技术的博客里面提到的他们内部采用的代码管理方式，区别于GitFlow，核心点在于没有固定Develop分支，要发布的时候把要上线的Feature分支一起合并到一个Release分支，这样做的好处是需求变更哪个Feature不要了，只需要把其他Feature分支重新合并到新的Release分支即可。

Aone Flow模型

三、云音乐代码分支管理

那云音乐需要怎么样的代码分支管理方法？我们适应目前双周迭代的分支管理模型应该要满足这几点：

1、够敏捷但又管理可控

云音乐迭代了这些年后版本相对趋于稳定，对于一个千万级体量的中大型APP来说，稳定，风险可控是一个基本诉求。而在这前提下面如何保持一定的灵活度是需要一直探索和寻找的平衡点

双周迭代的重要特性通俗来讲就是“上下车”制度，或者叫赶班车，也即能灵活应对突发情况随时将一个需求挪到下个版本上线，或者将一个需求挪到这个版本上线，这就意味着Release分支的合入也需要非常灵活，这一点跟Aone Flow非常像。

2、流程稳定，认知清晰

所有开发同学都非常清晰双周迭代的节奏，也要非常清晰代码管理的方法，每个迭代周期往哪个上线分支合并，什么节点合入都是非常明确的。避免出现忘记合入不知道往哪里合入的问题，同时我们也希望把这部分合并工作能够分摊到每个开发，做到自己分支自己负责。

3、CodeReview是必需的

相信大家都能认可CodeReview的意义，最佳做CodeReview的时机往往是代码合入点，通过PR或者MR来发起。

4、方便持续集成流水线

传统方式因为大家都提交在自己分支上面，代码分散同时存在合并后产生额外风险，我们期望尽可能尽快把Feature分支集合起来走流水线。

为了解决这几个问题，我们需要几种分支：

1. 稳定的发布分支，统一大家认知确保在固定合入时机点前发起MR进行合入，我们固定叫release-xxxx分支，在下个迭代开始时从前一个Release分支拉出；
2. 稳定的主干分支（Master），只是作为HotFix分支拉取，当然其实HotFix也可以从已发布的Release分支或者Tag里面拉出，Master的意义在于确保一条可以随时发布的干净的版本记录；
3. 若干开发分支，这个Feature分支和GitFlow，AoneFlow没有差别，在合入Release分支的时候进行CodeReview，我们固定叫feature-xxx；
4. HotFix分支，这个没有差别。

整体来看我们的最佳实践会是GitFlow和AoneFlow的结合体：

首先，把GitFlow的Develop和Release分支进行合并，减少复杂度。固定每个迭代的Release分支名字方便认知，对于客户端来说Release没有环境之分，不需要有多个Release分支；

不允许在Release上面提交代码，所有功能开发都走Feature分支，即便合并后有bugfix，仍然走Feature修改再次合入，这样确保所有代码合入都是测试完成且CodeReview完成。同时也具备AoneFlow的优点，一旦需求有要下车，则直接删掉Release分支进行重建，把其他Feature分支合入即可；

因为合入时间节点是固定的，所以Release分支持续集成的时间是固定的，我们一般是定在第二周的周二，虽然没有第一时间像TBD一样进行，但已经是我们想要找到的一个合理平衡点。当然Feature分支上面也可以有流水线，跑的东西略微有些差别（Feature分支跑的东西偏测试环境）

Master分支随时处于Release状态，确保HotFix能够及时进行。

云音乐目前的分支管理模型

四、其他

除了约定，云音乐内部还有叫做《全链路研发平台》的工具来辅助代码分支管理，这个平台涵盖了从需求产生到交付的全生命周期管理，包括需求排期、提测、打包、持续集成、卡点、发布等环节。和代码分支管理相关的主要有这些：

• 每个需求都会要求关联一个Feature分支，否则无法提测；
• 每个Feature分支是否合入当前迭代固定的Release分支状态可查询，方便管理版本上线前卡点。

最后，没有一个代码分支管理方法是直接适用自己的项目场景的，还是要根据实际情况进行一些取舍，找到一个最佳的平衡点。