阅读 222

我是怎么做git分支管理的

git分支管理模型挺多的,各种概念配图花里胡哨,对于初学者来说,看起来会比较累,可能理解不了。

我这里描述一下我个人是如何做分支管理的,有更好的方式或者建议欢迎评论区交流。

常驻分支

保持三个常驻分支对应三个环境

  • master —— 生产
  • develop —— 开发
  • beta —— 测试

一般情况下,各个公司都会有着不同的几个环境用于各项研发工作

名称大同小异,我这里截取几个比较常见的环境名称,分别对应生产,测试,开发

各位有几个环境,一般可以对应几个常驻分支

保护分支

master

master为保护分支,禁止直接通过本地提交,需要经由有授权的开发人员通过公司使用的git平台合并

git平台挺多的,各位的公司肯定有相关的平台选择,github gitee gitlab gitea等等

建议,beta,develop分支也由平台发起合并操作,不要在本地进行合并提交操作。

这样合并的过程,一定是有授权人员知晓的

如果有codeReview过程,这个合并期间就能做了

分支约定

命名


功能性迭代需求

采用feature/开头。后面跟上对应的本项目版本号,不带v

场景用例:

比如某平台,我们称呼为AAA平台,当前已发布的线上版本为v6.0.0

  1. 产品A由于某产品需求,需要对AAA平台进行改动,则新迭代分支由master拉出为feature/6.0.1

  2. 同期产品B由于由于某产品需求,需要对AAA平台进行改动,由产品AB协商

    是合并在一个迭代内开发,还是分开开发

    合并在一起,则使用feature/6.0.1开发

    否则,由master重新拉出分支feature/6.0.2进行开发

    两个分支均由master拉出,互不干扰


bugfix类型需求

采用bugfix/开头。后面跟上当前正在迭代的版本号,如果没有正在迭代版本,则新增

场景用例:

比如AAA平台,由代码扫描平台扫描发现漏洞,需要紧急修复(理论上这种问题出现的频次相对较低)

  1. 当前AAA平台的迭代分支为feature/6.0.1

    则从master拉取bugfix/6.0.1

    修复完成后通过合并到develop,beta验后,合并到master发布上线

  2. 合并到master以后,将master合并到所有的迭代分支上,即 且feature/6.0.1上线版本修正为v6.0.2


分支合并流程

均由单独的feature分支和bugfix分支往masterdevelopbeta分支合并

master有新的合并后,需要将master的代码合并到当前正在开发的迭代分支中

develop不会往betamaster合并!beta同理!

develop不会往betamaster合并!beta同理!

develop不会往betamaster合并!beta同理!

可以视情况而定,是否需要重建developbeta分支

说明

这里需要说明一下

为什么要把feature下的分支单独往master分支合并发布

而不是feature->develop->beta->master这样依次合并

假设存在多个迭代同时进行,但不是同时发版。

这里我用三个字母代表多个迭代a,b,c

他们的发版时间,分别某月1日,同月2日,同月3日。

假设在上个月30日,abc均完成迭代,发布到了beta环境。

那么在1日发版时,beta分支上存在bc的代码,无法剥离开来单独发版。

因此我们绝不能采用feature/合并到develop,develop合并到beta,beta合并到master这种方式来发版

发布流程

引入自动化平台,可用平台挺多的,jenkins spug等等

  1. 由自动化平台拉取master分支进行发布
  2. 上线验证完毕以后
  3. git平台发布release,生成tag填写版本好,带v
  4. 一定要填写本次发版内容!!!
  5. 删除对应迭代分支

对于某些由主干产品单独定制的业务产品

可能存在某些业务,又一个主干产品

同时有些客户要求定制化

这些定制化以后的需求,实际上就偏离了主干产品了

针对这种类型的产品,通过fork的方式拉出单独仓库,按照上述方式进行分支管理

因为通过fork方式,定制项目与主干项目存在关联性

可以通过合并的方式,将主干的某些内容合并到定制项目上

对于这类项目的发布,均由自动化平台的单独业务job发布

文章分类
前端
文章标签