git分支管理模型挺多的,各种概念配图花里胡哨,对于初学者来说,看起来会比较累,可能理解不了。
我这里描述一下我个人是如何做分支管理的,有更好的方式或者建议欢迎评论区交流。
常驻分支
保持三个常驻分支对应三个环境
- master —— 生产
- develop —— 开发
- beta —— 测试
一般情况下,各个公司都会有着不同的几个环境用于各项研发工作
名称大同小异,我这里截取几个比较常见的环境名称,分别对应生产,测试,开发
各位有几个环境,一般可以对应几个常驻分支
保护分支
master
master为保护分支,禁止直接通过本地提交,需要经由有授权的开发人员通过公司使用的git平台合并
git平台挺多的,各位的公司肯定有相关的平台选择,github
gitee
gitlab
gitea
等等
建议,beta,develop分支也由平台发起合并操作,不要在本地进行合并提交操作。
这样合并的过程,一定是有授权人员知晓的
如果有codeReview
过程,这个合并期间就能做了
分支约定
命名
功能性迭代需求
采用feature/
开头。后面跟上对应的本项目版本号,不带v
场景用例:
比如某平台,我们称呼为AAA平台
,当前已发布的线上版本为v6.0.0
产品A
由于某产品需求,需要对AAA平台
进行改动,则新迭代分支由master
拉出为feature/6.0.1
-
同期
产品B
由于由于某产品需求,需要对AAA平台
进行改动,由产品A
和B
协商是合并在一个迭代内开发,还是分开开发
合并在一起,则使用
feature/6.0.1
开发否则,由
master
重新拉出分支feature/6.0.2
进行开发两个分支均由
master
拉出,互不干扰
bugfix类型需求
采用bugfix/
开头。后面跟上当前正在迭代的版本号,如果没有正在迭代版本,则新增
场景用例:
比如AAA平台
,由代码扫描平台扫描发现漏洞,需要紧急修复(理论上这种问题出现的频次相对较低)
-
当前
AAA平台
的迭代分支为feature/6.0.1
则从
master
拉取bugfix/6.0.1
修复完成后通过合并到
develop
,beta
验后,合并到master
发布上线 合并到
master
以后,将master
合并到所有的迭代分支上,即
且feature/6.0.1
上线版本修正为v6.0.2
分支合并流程
均由单独的feature
分支和bugfix
分支往master
,develop
,beta
分支合并
当master
有新的合并后,需要将master
的代码合并到当前正在开发的迭代分支中
develop
不会往beta
和master
合并!beta
同理!
develop
不会往beta
和master
合并!beta
同理!
develop
不会往beta
和master
合并!beta
同理!
可以视情况而定,是否需要重建develop
和beta
分支
说明
这里需要说明一下
为什么要把feature
下的分支单独往master
分支合并发布
而不是feature
->develop
->beta
->master
这样依次合并
假设存在多个迭代同时进行,但不是同时发版。
这里我用三个字母代表多个迭代a
,b
,c
他们的发版时间,分别某月1日,同月2日,同月3日。
假设在上个月30日,abc均完成迭代,发布到了beta
环境。
那么在1日发版时,beta
分支上存在b
和c
的代码,无法剥离开来单独发版。
因此我们绝不能采用feature/
合并到develop
,develop
合并到beta
,beta
合并到master
这种方式来发版
发布流程
引入自动化平台,可用平台挺多的,jenkins
spug
等等
- 由自动化平台拉取
master
分支进行发布 - 上线验证完毕以后
- git平台发布
release
,生成tag
填写版本好,带v - 一定要填写本次发版内容!!!
- 删除对应迭代分支
对于某些由主干产品单独定制的业务产品
可能存在某些业务,有一个主干产品
同时有些客户要求定制化
这些定制化以后的需求,实际上就偏离了主干产品了
针对这种类型的产品,通过fork
的方式拉出单独仓库,按照上述方式进行分支管理
因为通过fork
方式,定制项目与主干项目存在关联性
可以通过合并的方式,将主干的某些内容合并到定制项目上
对于这类项目的发布,均由自动化平台的单独业务job发布