「Branching Model」- 分支模型 @20210418
码云中的分支模型
单分支模型 (只创建 master 分支)
生产/开发模型 (支持 master/develop 类型分支)
特性/发布模型 (支持 master/develop/feature 类型分支)
开发/发布分离模型 (支持 master/develop/feature/release 类型分支)
开发/发布/缺陷分离模型 (支持 master/develop/feature/release/bugfix 类型分支)
git-flow [支持自定义]
开发分支 develop
功能分支 feature
发布分支 release
补丁分支 hotfix
Trunk Based Development
「Trunk Based Development」
master(1)\release(n)
该模型是CI思想所崇尚的工作方式，它由单个master分支和许多release分支组成，每个release分支在特定版本的提交点上从master分支创建出来，用来进行上线部署和热修复。在该模式中，没有显性的feature分支。
Git Flow
「Gitflow Workflow」
master(1)\develop(1)\feature(n)\release(n)\hotfix(n)
该模型是若干模式的集大成者，包含一个master分支、一个develop分支、许多feature分支、许多release分支、许多hotfix分支，以及许多繁琐的合并规则。
Aone Flow
master(1)\feature(n)\release(n)
三条规则：
规则一：开始工作前，从master创建feature分支
从代表最新已发布版本的master分支上创建一个通常以「feature/」为前缀命名的特性分支，然后在这个分支上提交代码修改。也就是说，每个工作项（可以是一个人完成，或是多个人协作完成）对应一个特性分支，所有的修改都不允许直接提交到master分支。
规则二，通过合并feature分支，形成release分支
从master分支上拉出一条新分支，将所有本次要集成或发布的feature分支依次合并过去，从而得到release分支。release分支通常以「release/」前缀命名。
规则三，发布到线上正式环境后，合并相应的release分支到master分支，在master分支上添加tag，同时删除该release分支关联的feature分支。
为了避免在代码仓库里堆积大量历史上的feature分支，还应该清理掉已经上线部分feature分支。如果要回溯历史版本，只需在master分支上找到相应的版本的tag即可。
不成文的技巧：
上线后需要热修复：正常的处理方法应该是，创建一条新的release分支，对应线上环境（相当于hotfix分支），同时为这个分支创建「临时流水线」，以保障必要的发布前检查和冒烟测试能够自动执行。（其实还有一种简便方法：将线上正式环境对应的release分支上关联的feature分支全部清退掉，在这个release分支上直接进行修改，改完利用现成的流水线自动发布）
该模式兼顾了TrunkBased的“易于持续集成”和GitFlow的“易于管理需求”特点，同时规避掉GitFlow的那些繁文缛节。
相关文章
「Jenkins」- 重置密码
「Git」- 安装
「Jenkins」- 安装
「流水线模型」
「Git」- 提交空目录
「rsync」- 服务搭建（在GNU/Linux中）
「GitLab」- CI/CD
