我是怎么做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发布

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,189评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,577评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,857评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,703评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,705评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,620评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,995评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,656评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,898评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,639评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,720评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,395评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,982评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,953评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,195评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,907评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,472评论 2 342

推荐阅读更多精彩内容

  • 所有使用了本规范的项目,必须严格规范操作,否则不予以合并代码、提测、打包上线等后续操作。 branch使用规范 分...
    一瓶多先生阅读 820评论 0 1
  • Git 仓库申请流程 1. 开发主管向Git 管理员提交Git 仓库申请【邮件:发送给Git 管理员,抄送给项目经...
    骚包霸天虎阅读 2,070评论 0 0
  • 简介 现代软件开发过程中要实现高效的团队协作,需要使用代码分支管理工具实现代码的共享、追溯、回滚及维护等功能。目前...
    Lucas66阅读 8,157评论 0 5
  • 本文参考:Git ReferenceGit 分支模型 工欲善其事必先利其器,本文目的是列出常用的git命令,并简单...
    半瓶子响叮咚阅读 508评论 0 0
  • 前言 从2019年上半年云音乐的客户端团队开始迁移到双周迭代后,随之而来的是我们需要重新调整代码分支的管理方法,来...
    想飞的小小小鱼阅读 1,405评论 0 0