Git分支模型二

Git分支模型一中阐述了一种较为复杂的git分支工作流,其核心思想是参考了Linux等超大项目的工作流机制,可能更觉适合一些迭代较为频繁复杂以及合作人数较多的场景。

本篇文章将会阐述另一种git工作流机制,更加适用较为简单的场景。

思路

为了减少分支的种类和复杂型,将不再采用除了master之外的 LTS (long time support) 类型的分支,按 功能性 将分支分为以下几种,

  • feature-:feature-id
  • author/feature-:feature-id
  • release-:release-version
  • author/hotfix/feature-:feature-id
  • maint-:issue-id

这样,一个完整的工作流可能如下图所示,

下面将作具体的说明。

master分支

master分支作为版本库中 唯一的 长期分支,也是版本库的 主线 ,其作用是用于 发布线上代码 。 即 线上产品跑的代码就是master分支上的代码

Tips : 版本库中除了master分支之外,其他 所有的 分支皆是 临时分支

2.2 feature分支

当产品产出了新的需求后,理论上,需求都应该有一个确定的迭代周期,这个迭代周期即是需求的生命周期。

在具体的开发工作之前,我们应该做一项工作: 需求分解 。( 需求分解的相关文章将会在后面给出

需求分解 工作之后,我们将会得到一系列的 需求点feature point ) ,同一个迭代周期的需求点将会都被包括在同一个 Milestone 中。此处我们将需求点抽象成相应的issue,每一个需求将会有一个 issue-id ,这样,我们feature分支的命名规则就形成了。

feature + - + feature-id

如上图中的feature-11feature-12等。

此处的feature-id即是每一个需求点的 issue-id

所以,feature分支就是一个个需求点的实际产出。如上图中 橘红色 的分支。

Tips :feature分支都是从master分支迁出的,不过其归宿是后面将要说到的release分支。 (因为这其中涉及到功能非线性发布以及测试的问题)

author/feature分支

此分支相比feature分支多了一个author前缀!显而易见,author/feature分支将会与具体的rd相关联。

所以,它的作用就是, 针对某一需求点不同rd的合作实现 。其命名规则如下,

author + / + feature

如上图中的author1/feature-11等。

因为此分支跟具体的rd相关联,实际上它相当于某一rd的 个人开发分支 。一般情况下,rd的个人开发开发都是 由自己维护 ,别人不会涉及的。

Tipsauthor/feature分支都是从某一feature分支迁出的,经过一段时间的开发之后,它将会合并回之前的feature分支。

release分支

当我们有发布需求时,我们从master上的迁出release分支作为某一次发布的容器。

因为发布时会带有相应的版本信息,所以我们release分支的命名规则如下,

release + - + release-version

如上图中的release-1.0.0

一般情况下,当一个需求迭代周期即将结束的时候,我们进行功能发布。此时,我们将此次迭代周期中产生的 所有 feature分支合并进release分支,然后对此release分支提测。

release分支提测无问题

相比现在我们直接在master上进行测试这一做法,我们更加提倡先在相应的release分支进行 详细测试 ,若确认没有问题,将release分支合并进master分支,然后 再回归覆盖 master分支。

master分支经 回归覆盖 后,仍然没有问题,即可进行打 TAG 及打包动作进行发布。

release分支提测发现问题

release分支在提测中发现了问题,经过定位之后,确定问题来源(定位到相关的feature分支),由相应rd在相应的feature分支上迁出author/hotfix/feature分支进行快速修复。

修复完毕之后,rd自测进行确认,然后将hotfix分支合并至相应的feature分支,然后重复之前release分支提测的动作。

feature分支非线性发布

在实际的功能发布中,我们可能遇到这样一种情况,

一个迭代周期进行 多次发布 ,每次发布仅包含所有feature分支中的某几个。

针对这种情况,我们在迁出特定的release分支之后,将需要发布的feature分支合并进release分支即可,后面操作与之前并无二样!

这样就可以使用不同的release分支进行非线性发布,他们的区别在于release分支的版本号不同。

Tipsrelease分支由master分支迁出,最终也将合并进master分支。

author/hotfix/feature分支

如前所述,当release分支进行提测时发现问题时,进行定位之后,由相应rd进行修复动作。

所以auther/hotfix/feature的命名规则如下,

author + / + hotfix + / + feature

如上图中的 author8/hotfix/feature-11

需要注意的一点是,快速修复分支与之前的author/feature分支一样,都是属于 个人开发分支

Tipsauthor/hotfix/feature分支从feature分支迁出,最终也将合并进feature分支。

maint分支

线上代码可能会出现各种问题,比如

  • 用户反馈的问题
  • 可以优化的地方
  • 测试未被发现的问题
  • ...

这里的maint分支就是为这些问题准备的,它的作用就是维护master分支上可能出现的各种问题。

轻量维护

当出现这些问题之后,相关人员会在 issue list 中提出相关 issue ,所以maint分支的命名规则如下,

maint + - + issue-id

如上图中的maint-44

多人维护

此外, 这里还可能会出现另一种情况 ,就是,

issue 中的问题涉及 多名rd ,需要合作修复时,此时maint分支将会有一种变形,

author + / + maint + - + isuue-id

如上图中的author8/maint-45author9/maint-45

维护完毕

maint分支的修复工作完成之后,需要进行相应的修复发布,这里的操作与之前的release分支类似,具体可以请参阅上图。

这里,有一个问题需要提一下,

maint中涉及的问题比较轻量,属于那种可以快速修复的,这种情况下,可以略过release分支,减少提测过程,简化发布操作。如图中的maint-44分支。

具体如何操作应该视具体情况来确定。

总结

  • 在具体的开发及修复工作之前,应该明确问题,确定使用哪一种分支
  • 规范分支的命名
  • 维护好自己的个人分支,避免分支泛滥
  • 公用分支避免相互合并,feature分支的迁出及release分支的合并最好由一个人来操作
  • 将个人分支合并进公用分支之前,尽量压缩冗余的无用的改动集,保持公用分支的干净
  • 进行代码合并操作时,应该尽量使用 merge requestcode review ,明确每次合并动作带来的结果是否符合预期
  • ...