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平台进行改动，由产品A和B协商

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

   合并在一起，则使用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分支往master，develop，beta分支合并

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

可以视情况而定，是否需要重建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等等

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

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

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

同时有些客户要求定制化

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

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

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

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

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