Git规范最佳实践
一、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 分支原则上备份留档，不做任何操作。
