分支的目的是隔离,但多一个分支也意味着维护成本的增加。我们可以分别从开发和发布分支的多寡,做个简单组合,即:

主干开发,主干发布。
分支开发,主干发布。
主干开发,分支发布。
分支开发,分支发布。
设想两个不同的场景:

如果一个软件,只有一个开发者,只需要一个发布版本,那他需要什么样的分支模式?

如果一个软件,有 10 位开发者,需要支持多个版本,那他们又需要什么样的分支模式?

一个好的分支模式,可以大大提高软件的开发、集成和发布效率。选择什么样的分支策略,是每一个开发团队开始工作时面临的第一个问题。那么,选择什么样的分支模式才适合我们呢?在回答这个题之前,我们先了解一下几种常见的分支模式。

主流的分支模式

常见的分支模式有 TBD(即主干开发模式)、Git-Flow 模式、Github-Flow 模式及 Gitlab-Flow 模式。

TBD(主干开发模式)

即所有开发者,仅在一个开发分支(即主干)上进行协作开发的模式,在这种模式下,不允许新建任何长期存在的开发分支,有且仅保留主干分支进行开发协作。

因为没有长期分离的其他开发分支,任何代码变更持续地更新到主干上,在一定程度上避免了 merge 代码带来的困扰。同时,在这种开发模式下,建议采用发布分支的策略,根据软件版本的发布节奏拉出发布分支。在 TBD 模式下,所有的修改都是在主干上,哪怕是缺陷的修改也是,修改完缺陷后,再 cherry pick 到发布分支上。

其特点总结一下就是:

有且仅有一个开发分支,即主干分支。

所有改动都发生在主干分支。

发布可以从主干拉发布分支。

主干上进行的修复需要根据缺陷的修复策略,确定是否 cherry pick 到对应版本的发布分支。

标签: none

添加新评论