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 分支原则上备份留档，不做任何操作。