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-11，feature-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的个人开发开发都是 由自己维护 ，别人不会涉及的。

Tips ：author/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分支的版本号不同。

Tips ：release分支由master分支迁出，最终也将合并进master分支。

author/hotfix/feature分支

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

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

author + / + hotfix + / + feature

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

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

Tips ：author/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-45，author9/maint-45。

维护完毕

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

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

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

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

总结

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