浅谈生产发布中的分支管理模式

发布分支

* 一个分支，它只接受为稳定准备发布的产品版本而做的提交。*

我们可以将分支看作是对代码库的特定提交序列。分支的头或顶端是该序列中的最新提交。

将产品当前状态的单个共享分支作为主线，一个典型的发布分支将从当前主线复制，但不允许向其添加任何新功能。主要开发团队将继续向主线添加新功能，这些功能将在未来的发布中获得。开发人员在发布时只专注于消除任何阻碍发布做好生产准备的缺陷。对这些缺陷的任何修复都是在发布分支上创建的，并合并到主线中。当没有更多的缺陷需要处理时，分支就可以进行生产发布了。在合并过程中可能会因为冲突产生大量的工作，因此这里用一块黄色标记合并。

在生产中只有一个版本的团队只需要一个发布分支，但有些产品会有许多版本在生产使用中。在客户终端上运行的软件只有在客户希望的时候才会升级。许多客户不愿意升级，但是这些客户仍然希望修复错误，尤其是在涉及安全问题时。在这种情况下，开发团队会为每个仍在使用的版本创建发布分支，并根据需要对其进行修复。

成熟度分支

* 一个分支，其头部是标记代码库成熟度级别的最新版本。*

当代码库的一个版本达到一定的准备程度时，就会被复制到特定的分支中，这个分支就是成熟度分支。对于生产的成熟度分支，当准备好生产发布时，创建一个发布分支来稳定产品，当产品稳定后，将它复制到一个长期运行的生产分支。注意这里是复制而不是合并，因为我们希望生产代码与上游分支上测试的代码完全相同。

成熟度分支通常以开发流程中的适当阶段命名。比如“生产分支”、“临时分支”和“QA分支”等。偶尔也有人把生产成熟度分支称为“发布分支”。

环境分支

* 通过应用源代码提交将产品配置为在新环境中运行。*

系统通常需要在不同的环境中运行，例如开发人员的开发测试环境、生产服务器等。在这些不同的环境中运行需要一些配置更改，例如用于访问数据库的URL、消息传递系统的位置以及关键资源的URL等。

环境分支是包含提交的分支，这些提交应用于源代码以重新配置产品在不同的环境中运行。假设在主线上运行3.2版本，现在希望在临时服务器上也运行它。那么通过从版本3.2开始创建一个新的分支，应用适当的环境配置，重新构建产品，并将其部署到临时环境中。

环境分支通常与成熟度分支相结合。长期QA成熟度分支可以包括针对QA环境的配置更改。合并到此分支之后，将获取配置更改。类似地，一个长期存在的发布分支也可能包括这些配置更改。

修复程序分支

* 为修复紧急生产缺陷而创建的分支。*

如果生产中出现了严重的bug，则需要尽快修复。与团队正在做的任何其他工作相比，解决这个bug的工作优先级更高。可以从最新发布的版本开始创建一个新分支并在该分支上进行bug修复。

当修复程序应用于生产后，就可以集成到主线，以确保下一个版本不会出现倒退。如果团队正在使用发布分支，则可以在发布分支上进行修复工作，并在完成后创建新的发布分支。从本质上讲，这将旧的发布分支变成了修复程序分支。

如果一个团队进行持续交付，可以直接从主线发布修复程序，也可以仍然使用修复程序分支，但是需要从最近的提交开始，而不是从最后发布的提交开始。

发布列车

* 在设定的时间间隔内发布，就像火车按常规时间表发车一样。开发人员在完成其功能后选择要赶上的列车。*

使用发布列车的团队将设置定期的发布节奏，例如每周或每个月发布一次。开发人员决定他们想要功能赶上哪列列车，并将工作目标对准那列列车，在列车装货时将他们的提交放在适当的分支上。一旦列车发车，该分支就是一个发布分支，只接受修复。

一个使用月度发布列车的团队，设置了固定发布日为每月的第三个星期一。该团队在三月份发布的基础上，创建了一个四月分支。随着时间的推移，四月分支将增加新的功能。在发布日，四月发布列车发车，冻结了四月分支。这时，在四月分支的基础上创建了一个五月分支，并为五月分支增加了新的功能。与此同时，开发人员稳定了四月发布列车，并在四月发布列车准备就绪后将其投入生产，而针对四月发布列车做的所有修复都将被合并到五月发布列车。

发布列车通常与功能分支一起使用。功能开发的周期决定了坐哪列列车。一些团队在列车出发前几天使用软冻结。当发布列车处于软冻结状态时，开发人员就不应该再将更改推送到该分支上，除非他们确信自己的功能是稳定的并准备好发布。软冻结后添加的任何显示错误的功能都将被回退，而不是在发布列车上修复。

发布就绪主线

* 保持主线足够健康，使主线的头部始终可以直接投入生产。*

如果主线是一个健康的分支，并且对主线的健康检查足够高，那么就可以随时在主线上直接发布，用标签记录发布。

对主线的每一次提交都是可发布的，并不意味着它应该被发布。这就是持续交付和持续部署之间的细微区别。使用持续部署的团队确实会将提交的每一个更改发布到主线，但使用持续交付，虽然每个更改都是可发布的，但是否发布是一个业务决定。因此，持续部署是持续交付的一个子集。我们可以将持续交付视为给我们随时发布的选择，我们行使该选择的时机取决于业务需求。

结语

分支容易，合并更难。合理地使用分支是多个开发人员贡献于单个代码库的关键。这里我总结两点：一是，在考虑使用分支时，要先弄清楚如何合并。如果不了解合并的成本，就无法做出恰当的决定，会给后续集成工作带来很大困难。二是，在选择使用分支时，确保分支的最优选择方案。作为分支中最困难的部分，在进行合并时，需要特别注意使合并变得困难的原因。合并中出现的所有问题，尤其是给团队带来危害的问题，都是提高团队效率的标志。根据合并中出现的问题，及时调整，直至找到分支的最优选择方案。