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发布
网友评论