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

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

常驻分支

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

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

通常状况下，各个公司都会有着不一样的几个环境用于各项研发工做markdown

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

各位有几个环境，通常能够对应几个常驻分支app

保护分支

mastergitlab

master为保护分支，禁止直接经过本地提交，须要经由有受权的开发人员经过公司使用的git平台合并测试

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

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

这样合并的过程，必定是有受权人员知晓的spa

若是有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分支

说明

这里须要说明一下

为何要把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发布

我是怎么作git分支管理的