一、git分支策略
分支
master 分支
master
为主分支,仅用作存档,不做部署使用
,一般由release
或hotfix
分支合并,任何情况下不允许直接在 master 分支上修改代码,且master
一般会由仓库owner
设置为保护分支.
master分支说明:
master:产品化项目主分支;
master-xzsn:定制化项目xzsn主分支;
master-lzcx:定制化项目lzcx主分支;
其他......
feature 分支
feature
为需求开发分支,命名规则为feature/{需求简称}
开头,一旦该需求上线,便将其删除。这么说可能有点不容易理解,接下来举几个开发场景。
feature分支通常是以开发人员进行检出的,例如需要开发token过期校验的需求,则从master分支迁出 :feature/token-expire
release 分支
release
为上线分支,用于部署到预上线环境FAT
,UAT
,PRE
和PRO
注意:所有线上环境镜像均由
release
分支构建
其中 FAT 分支使用:release 分支自动构建镜像,将 feature 分支合并至 release 分支则自动构建镜像,生成的镜像版本为snapshot;
UAT 和 PRE 使用: v{版本号}-beta.{修复次数} tag构建镜像;
PRO 使用: v{版本号}-release.{修改次数} tag构建镜像;
热修复版本使用: v{版本号}-hotfix.{修复次数} tag构建镜像;
- 示例:
以下均为镜像:
micro-gateway:snapshot ---> 用于fat版本部署
micro-gateway:2.0.0.0-beta.01 ---> 用于uat和pre版本部署
micro-gateway:2.0.0.0-release.01 ---> 用于pro正式部署
micro-gateway:2.0.0.0-hotfix.01 ---> 用于pro线上问题热修复部署
注意: 始终保持与 master
分支一致,一般由 release
或 hotfix
分支合并,不建议直接在 release
分支上直接修改代码。如果在 release
分支测试出问题,需要回归验证 feature
分支是否存在此问题。正式版本和beta版本的最大值节点一致。
上线完成之后将 release
分支合并到 master
分支。
hotfix 分支
hotfix
为热修复分支,命名规则为hotfix-{修复版本}
开头。当线上出现紧急问题需要马上修复时,需要基于release
或master
分支创建hotfix
分支,修复完成后,再合并到release
和master
分支,一旦修复上线,便将其删除。
二、版本号策略
分支规则
因
feature
和release
分支可能较多,故约定创建规则。
- 示例:
常规迭代版本如:1.1.0.0 对应的feature构建规则: feature/token-expire(需求简称)
常规迭代版本如:1.1.0.0 对应的release构建规则: release/1.1.0.0
客制化迭代版本如:1.0.0.0 对应的feature构建规则:feature/tobacco-token-expire(需求简称)-- (按需)
客制化迭代版本如:1.0.0.0 对应的release构建规则:release/1.0.0.0-tobacco(tobacco代表客制化项目代号)
版本号说明
上述介绍中的版本号均使用
pingcode
中的立项版本号,必须严格一致。(关于pingcode中的版本号与正式环境的版本号对应不起来的问题,解决方案:tag的版本号-release.01排序)
- 示例:
常规迭代版本如:1.1.0.0 对应的镜像tag为: micro-gateway:1.1.0.0-release.01
运维迭代版本如:1.1.0.1* 对应的镜像tag为: micro-gateway:1.1.0.1-release.01
客制化迭代版本如:1.0.0.0对应的镜像tag为: micro-gateway:1.0.0.0-tobacco-release.01
分支和tag管理
由仓库
owner
定期维护管理分支和tag,一般建议将master
分支设置为保护分支,只允许开发者往master
分支上merge代码,定期移除冗余的feature
、release
分支和tag。
版本Tips
版本号必须符合semver,其的形式为{major}.{minor}.{patch}[-{pre-release-type}.{pre-release}]
其中major、minor、patch和{pre-release}`必须为十进制数字,且随版本发布递增。
{pre-release-type}必须选择以下关键词之一:
alpha表示内部测试版本,不建议任何非参与开发人员所在团队使用,在alpha版本期间会不断增加新的功能并修复已有BUG ===>客制化项目酌情使用
beta表示公开测试版本,不建议稳定项目使用,在beta版本期间会酌情增加新功能,修复已知BUG ===>对标uat和pre
v{版本}表示正式环境版本,用于正式环境上线以及代码存档节点.
三、客制化项目约定示例
-
流程图示例:
-
以下以客制化项目示例:
-
第一步:决策项目
因客制化项目作为设施化农业项目,后续较多功能可能会合并至产品化项目,所以仍然使用产品化项目既有仓库,通过初始化不同的分支来区分项目
- 第二步:创建feature分支
从各项目master分支签出分支: feature/xxxxx(不同开发人员可以自定义自己签出的feature分支);
各端开发人员基于feature分支进行功能开发;
- 第三步:创建release分支
从各项目master分支签出分支: release/1.0.0.0-tobacco
其中:1.0.0.0代表pingcode上的发布版本号,tobacco代表项目代号(项目代号建议优先以英文名称命名)
注意,release分支由各端负责人签出(时间节点:测试环境提测前或开发人员合并feature特性前);
开发人员基于开发的feature/xxxxx进行代码合并,若代码冲突的情况下,解决冲突后合并并推送至release分支。
- 第四步:构建部署tag/上线
1.release分支会自动构建项目镜像,如分支release/1.0.0.0-tobacco 监测到代码合并之后,自动构建镜像版本: 1.0.0.0-tobacco-snapshot,该版本适用于fat环境部署;
2.uat和pre环境上线前,由开发人员统一构建 1.0.0.0-tobacco-beta.01 tag版本;
3.pro环境上线前,由开发人员统一构建 1.0.0.0-tobacco-release.01 tag版本。
- 第五步:合并master分支
系统版本经过上线之后,在上线后第二天由各端负责人发起 merge request,由项目或仓库 owner 从release/1.0.0.0-tobacco 合并至 master-tobacco
- 第六步:定期维护分支
由仓库owner和项目经理决策分支是否保留,定期对冗余的feature分支进行清理,release 和 master 分支原则上备份留档,不做任何操作。
标签:Git,0.0,实践,feature,最佳,master,版本,release,分支
From: https://www.cnblogs.com/Alex-Tann/p/18122894