Git分支模型一

场景

  • 一个迭代周期中包含多个feature,但是feature可能彼此相互独立,亦可能相互依赖。
  • feature往往由多名职责不同的rd做具体不同的实现。
  • 迭代周期中的feature在上线时往往并不是线性的。
  • feature实现与测试相互割裂。
  • 维护及bug修复工作最好是可以持续的、可追溯的。

解决思路

除了master分支之外,我们将设立如下几个 LTSlong-time support )分支,

  • develop 日常开发分支
  • maint 日常维护及bug修复分支

除了masterLTS 分支之外,我们还将会有一些特殊用途的 临时分支

  • feature/:feature-id 功能开发分支
  • release/:release-version 预发布分支
  • bugfix/:author/:what 相应rd针对特定问题的调试追踪分支
  • :author/:what 不同职责rd的个人开发分支
  • :author/hotfix 相应rd的快速修复分支

下面针对这些分支分别做详细的说明。

master分支

master作为版本库的默认分支,有且只有一个,往往作为代码的发布分支,即 线上产品跑的代码 = master分支上的代码

一般而言,不推荐在master分支上直接提交代码。

develop分支

master分支的作用是用来发布版本更新的,那么develop分支就是用来做日常的开发工作的。 在最开始的时候,develop分支是由master上迁出的

develop分支是一个 LTSlong-time support )分支,即它和master分支一样,其生命周期贯穿整个版本库的生命周期。

当在develop分支的开发告一段落之后,我们将develop合并到master分支即可。(这里暂时忽略测试的环节,后面会有详细的说明。)

如上图所示,develop分支在开发一段时间后,我们将其合并到master分支中。

这里有一点需要特别提出来作说明, 我们推荐使用 --no-ff 的形式进行分支合并

是否使用--no-ff的区别如下,

可见,

  • --no-ff方式进行合并,总是生成合并提交改动
  • 快进方式进行合并,将会试图将不同的分支保持在一条branch line上

为了保证版本演进的清晰,我们希望采用这种做法。关于合并的更多解释,请参考Benjamin Sandofsky的《Understanding the Git Workflow》

maint分支

maint分支是一个 LTS 分支,其作用是用于主线branch的日常维护及bug修复。

往往我们会遇到这样一个场景,

刚刚发布了一个新的版本,可是一些细节的小问题在review及test的时候由于种种原因都未能发现。此时我们需要一个能够及时修复的解决方案,maint分支产生了。(这仅是maint分支作为 LTS 分支存在的原因之一,这里仅仅是用来举例。)

从某一种意义上说,maint分支是master分支的 影子

总结,

  • maint分支 master分支迁出
  • 在使用maint分支之前,应该先检查是否落后当前的master分支,如果落后,则应该 先对maint分支进行rebase操作 (这里就体现了maintmaster的影子这一观点 )
  • 一般来说,同一时刻只会有一个问题需要在maint分支上进行快速修复,因为致命问题经过review和test后还未被发现的概率应该是比较小的。

feature/:feature-id分支

一个迭代周期将会对应一个milestone,在milestone中将迭代需求分解成众多的feature point,在milestone中以issue的方式提出。 即 一个issue-id将会对应feature point ,此issue-id即为feature-id

如上图所示,所有的feature分支,

  • 都是 临时 分支
  • 都是 develop分支迁出
  • 理论上 都是彼此相互独立的

release/:release-version分支

所谓的预发布分支,从某种意义上来说就是一个测试分支。

在发布正式版本之前(即将feature分支合并到master分支之前),我们可能需要有一个预发布的版本进行测试。

若预发布分支在测试的过程中 没有遇到问题 ,比如预发布分支release/v1.0.0经测试未发现问题,则将此预发布分支分别 合并进master分支和develop分支 ,如下图所示:

若预发布分支在测试的过程中 遇到问题 ,比如预发布分支release/v1.0.1经测试发现了问题,则此时QA及bug发现者应该在issue list中贡献相应的bug描述,并分配相应的rd进行修复。

rd在feature分支上迁出:author/bugfix/:what分支进行修复工作,修复完毕之后合并进feature分支,最后将修复后的feature分支再合并进之前出问题的预发布分支再次进行测试。如下图所示:

总结,

  • release/:release-version分支都是 develop分支迁出
  • 将需要发布的 任意多个 功能分支feature/:feature-id合并进预发布分支进行测试
    • 可以灵活的针对需要发布或者测试的feature分支进行
  • 测试过程中遇到问题,要追溯到相关的feature/:feature-id分支上并迁出bugfix/:author/:what分支( 此分支更多的相关说明,请参见bugfix/:author/:what分支 )进行修复工作
  • 测试通过之后,将预发布分支分别合并到master分支和develop分支中
  • 视具体情况 删除预发布分支和feature分支

bugfix/:author/:what分支

release/:release-version中进行测试时,可能将会遇到各种bug。此时QA及bug发现者应该在issue list中贡献相应的bug描述。

如下图所示,

某一rd接到分配的issue时,即可开始在相应的feature/:feature-id分支中迁出bugfix/:author/:what分支进行相关修复工作。

其中:what变量一般跟随 issue-id ,修复完毕之后,将bugfix分支合并进相应的feature分支。

比如上图中 issue88 的assignee应该在相应的feature分支迁出bugfix分支 bugfix/gejiawen/issue88

:author/:what分支

此分支用于各rd针对不同feature的具体实现。其中:what变量的内容由rd自行确定。

总结,

  • :author/:what分支将是rd的具体实现,其命名和数量一般来说都没有限制
  • :author/:what分支 必须由某一特定的feature分支迁出的
  • rd在:author/:what分支上完成具体实现后,可以merge到相应的feature分支进行自测。
  • :author/:what分支一般来说依赖:author变量进行追溯,如需必要请勿修改他人的实现分支

2 一般原则

  • 明确 LTS 分支与 临时 分支之间的所属关系
  • 若无必要,请勿在他人的个人分支上工作
  • 常用git branch -a | grep :author管理自己名下的分支
  • 一般而言,master, develop, maint, feature-:feature-id之间不推荐相互merge
  • ...