做为一名测试，对代码管理多少会有些了解。比如当我们测试一个新功能的时候，研发会说：“你在某某分支上验证”，还有当我们需要集成包的时候，研发也会说：“等我把代码合并一下”。这里的“分支”和“合并”，都是代码管理中的常用词。

那为什么需要代码分支？代码合并又是合到哪里？最后发布用的是什么？紧急缺陷要怎么处理？所有这些问题的背后，其实都有着质量方面的考量。今天作者就从测试的角度，来深入剖析下代码管理的那些事。我们不妨重头开始，逐步构建出一个庞大的代码帝国。

Git 是当前比较流行的版本管理工具，接下来主要还是基于它来进行解读（SVN 可类推）。Git 的默认分支是 Master，现在假设不再需要其他分支，所有团队成员直接在 Master 上提交自己的代码，我们一起来看看到底会发生什么。

由于 Master 随时可能会有新的代码合入，一来会导致彼此之间相互影响，测试过程频繁被阻断；二来当前的测试结果会被破坏，可靠性无法得到保证。也就是说，质量上的成本和风险均会成倍增长，这显然不是一个明智的做法。

有人会采用一种变通的办法：指定某段时间不允许提交代码，只专注于测试，待验证通过之后再进行部署。这种做法也存在一定风险，倘若需要紧急发布（比如严重缺陷修复），因为只有一个分支，就不得不连同未经测试的代码一起部署。

单分支模式还有一个隐患是，万一其中部分代码出现问题（比如临时砍掉某个需求），由于所有代码都合到了一起，我们无法针对特定代码进行隔离和回滚，需要付出很大代价才能完整移除新增代码。

正因为这种种不便，所以单分支模式几乎不会出现在实际的团队协作场景中。

即然不能在 Master 上完成所有代码活动，很自然的，我们就会想到利用多分支的方式进行管控。当我们需要变更代码的时候（不论 feature 或 hotfix），都从 Master 上创建一个新的分支进行开发，待测试通过之后再合并回 Master 进行部署。

这种代码管理方式比较简明（相对后续要讲的 Git flow），适合有快速迭代诉求的持续集成模式，是 Github 较为推荐的做法，所以也叫 Github flow。（需要说明的是，任何模式都只是一种建议，而不是一种规定。）

相对于单 Master 分支的模式，Github flow 提供了稳定的分支测试环境，能够保证充分的分支测试时长，并且当分支出现问题时，即不会阻塞其他分支，也不用考虑回滚。然而即便有着这些优点，但它对质量保障的能力要求却很高。

由于 Master 是个随时可以发布的分支，并且合并的频率相对比较高，所以可用于集成测试的时间窗口很短。我们必须拥有通过单测及其他自动化手段，进行快速、全面的回归验证的能力，否则测试很容易被这种连续高频的变更拖垮。

对于没那么“精悍”的团队，我们需要一种兼顾分支和集成的方式。

沿着这个思路，为了保持 Master 的稳定，我们又建立了一个 Develop 分支，用来承担集成测试的责任。新的功能分支从 Develop 分支创建，紧急修复分支从 Master 分支创建，集成测试环境则基于 Develop 分支来部署。

因为 Develop 不作为生产部署的分支，所以我们可以一直在它之上进行充分的测试，直至认为达到了发布的标准，即可将 Develop 分支合入 Master，而后基于 Master 分支完成生产环境的部署。

这里面还有一个问题是，Develop 分支仍然会面临随时都有新代码合入的局面，虽然它不会影响生产环境的部署，但是这种不确定性仍然会导致集成测试的结果不稳定（参考单 Master 分支的问题）。

为了解决这个问题，我们可以制定一个机制，在集成测试的时间段内，禁止新的分支合入 Develop（因为 Hotfix 是从 Master 创建的，所以不用担心紧急修复的情况），待集成测试通过并且合入 Master 之后，再重新开放合并操作。

直至为止我们已经做得挺好的了，那么还有没有优化的空间呢？

虽然我们可以通过控制 Develop 的合并时间窗口，来保证集成测试环节的稳定，但这种做法其实很不“敏捷”。因为在非窗口期，所有就绪的分支都只能原地等待，集成过程中（比如代码冲突、关联影响）可能发生的问题，均不能及时暴露出来。

为此我们可以进一步对分支进行分化，从 Develop 分支生成一个 Release 分支，Develop 分支用于持续集成，而 Release 分支用于集成测试。如此一来，完成的分支就可以随时往 Develop 上合并，也不用担心影响集成测试的稳定。最后得到的这张图，其实就是 Git flow。前面我们通过逐步推导的方式，来了解为什么它要这么设计。

虽然 Git flow 很有名气，但它确实比较复杂，所以很多团队也并未完全遵循这套模式，而是引入一些自己的特点。其他比较常见的模式除了前面提到过的 Github flow，还有一种 Gitlab flow，它是介于 Git flow 和 Github flow 之间的一个方案。

Gitlab flow 的特点是“上游优先”，即将开发环境、集成环境、生产环境（前者都是后者的上游）分别创建一个分支来对应，只有上游通过的内容，才能合并到下游做进一步的测试。

Git flow、Gitlab flow、Github flow 三者之间的复杂度从高到低，质量保障的能力要求从低到高。它们各自适用于不同的情况，没有绝对的好坏，也不是既定的标准。正因为代码的管理方式和质量保障有很大的关联性，所以我们需要去了解这些代码管理模式的区别，以便确定不同的质量流程和策略，达到最好的保障效果。