Git WorkFlow

前言

学生时代常常一个人维护一个Git仓库,所以很是随性,不管分支,永远在master上开发,commit message也随便写,工作之后才意识到Git的重要性。
其实Git的工作流跟一个产品的推进的工作流紧密相关,如何利用Git进行产品研发,产品测试,产品发布,快速修复缺陷,这些都在Git的分支管理中。

Git分支

  • master分支
    代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本,都在这个主分支上发布。
    主分支必须是可用的、稳定的、可直接发布的版本,不能直接在主分支上开发。

  • dev分支
    master主分支只用来发布重大版本,日常开发应该在另一个分支上完成,我们把开发用的分支,叫做dev。这个分支可以用来生成代码的最新隔夜版本(nightly),进行最新功能的体验。
    如果想正式对外发布,就在master分支上对dev分支进行合并(merge)。
    dev分支代码永远是最新的,所有新功能以这个分支来创建自己的开发分支,该分支只做合并操作,不能直接在该分支上开发。

  • feature分支
    功能分支的名字,可以采用feature-*的形式命名,以自己开发的功能命名。
    功能分支是分配开发不同的功能用的,从dev创建功能分支,然后完成相应功能开发后,通过重新整理commit记录,然后合并回dev分支并删除该功能分支。这里采用--no-ff

  • release预发布分支
    预发布分支名字,可以采用release-*的形式命名
    预发布分支是指发布正式版本之前(即合并到master分支之前),我们可能需要有一个预发布的版本进行测试,主要是提交测试团队进行测试
    预发布分支是从dev分支上分出来的,预发布结束之后(即测试没有问题之后),必须合并进dev和master

  • release-bug修复预发布分支
    修复预发布分支的bug,可以采用release-bug-*的形式命名
    在预发布版本测试出现bug时,从release分支创建分支进行bug修复,bug修复完成后在合并会release分支

  • master-bug紧急修补分支
    修补分支的名字,可以采用bugfix-master-*的形式。该分支是为了紧急修复线上的bug。
    软件正式发布之后,难免会出现bug。这时就需要创建一个分支,进行bug修补。修补bug分支是从master分支上面分出来的。修补结束之后,将hotfix分支提交测试进行测试,通过后直接合并进master和dev分支。

注:一个分支尽量开发一个功能模块,不要多个功能模块在一个分支上开发. feature分支申请合并之前,最好先pull一下dev分支下来,看一下有没有冲突,如果有冲突就先解决冲突后再合并回dev

Git工作流

  • (产品启动)创建代码仓库以及master和dev分支
  • (产品研发)从dev上切出一个feature分支进行开发,feature开发完毕,整理commit,然后合并到dev分支
  • (产品预发布)积攒足够的feature需要进行一次发布的时候,从dev拉release分支
  • (产品测试)将release分支交付测试团队进行系统测试,如果有bug,从release分支切release-bug进行bug修复,再合并到release,直到最终的测试通过
  • (产品发布)从release分支合并到master分支,并打上版本tag,编写release note;同时也合并到dev分支
  • (线上bug修复)从master分支切bugfix-master进行bug修复,然后提交测试进行测试,测试通过之后合并到master和dev,对master打上新的tag。

如果在小团队也可以精简一下,只有一个master分支,不用dev分支,其他逻辑不变。


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!