# 十二、GIT分支及API JAR上传规范 **开发环境分支管理：** 对于小型的项目，可以使用 feature branch workflow，对于有明确开发、测试、发布周期的正式项目，建议使用 gitflow workflow。 对于 feature branch workflow只有经过审核的 Pull Request 可以提交到主分支 **有两种可以使用的工作流策略，** * **基于特性分支（Feature branch workflow）的工作流策略，** * **Gitflow** **工作流策略，详细的信息参考：[gitflow流程参考文档](https://www.cnblogs.com/jeffery-zou/p/10280167.html)** # **私有云：Gitflow 工作流策略** **]  * 功能分支（feature）：开发环境使用（Dev）开发者按照需求定义。只有经过审核的 Pull Request 可以提交到develop分支，开发分支上需要确保没有 P0 级别的缺陷 * 分支命名规范：feature\_{时间戳}\_{业务名}  以 JIRA 编号命名，例如 CL-1234 * 开发分支（develop）：测试环境（sit）固定使用，每周的功能迭代使用feature，一个迭代期完成后feature合并develop分支。 * 分支命名规范：develop:rtXX * 发布分支（release）：预发布环境、生产（UAT/PROD） 环境使用。当UAT环境测试通过后，release分支同时合并进入master与develop分支。运维人员使用rt\_xx 分支发布生产环境 * 分支命名规范：rt\_{序列号} * 主分支（master）：release分支发布完成后合并master 提交tag，并删除发布分支。 * 发布标签命名：rt1.0 * 热修复分支（hostfix）：hotfix开发分支从主分支对应的发布标签创建热修复开发分支。hotfix 分支需要同时合并master分支与develop分支。热修复版本发布后做发布标签，合并回主分支，并 cherry-pick 所有（或者必要的）改动到当前开发分支，并删除热修复开发分支 * 分支命名规范：rt1.1 主分支上需要确保没有 P0 级别的缺陷 对于 gitflow workflow只有发布分支可以合并到主分支 主分支上始终保存有发布质量的代码 # 发布时间节点 网站端每周发布一次，以 RT （Release Train）标记，代码锁定时间是每个周末（通常是周日晚上），发布时间是下周二晚上。代码锁定后到发布之间的代码修改需要使用 cherry-pick 方式。 # **规范：** **版本号：v X.X.X(.X)** **版本号为当期迭代确定的版本号，日常迭代合并master后打出对应迭代版本号的tag，4为迭代上线后线上问题hotfix修复版本号升级标识** **1****为主版本号，2为较大功能变更，3为小的日常迭代版本，4为hotfix** 开发分支 dev\_{YYYYMMDD}\_{v X.X.X}  feature分支（fea\_{YYYYMMDD}\_{v X.X.X}）不做强制要求，按迭代实际情况是否拉取 提测后打test\_tag\_{v X.X.X.X}进行SIT/UAT测试，如果有修改，重新提测，升级TAG版本 UAT测试完成以测试TAG最终版本test\_tag\_{v X.X.X.X}进行生产上线，上线验证完成后由测试合并master分支，打master\_tag\_{v X.X.X} 上线完成合并master后，其他开发分支需要将master分支内容合并到未完成的DEV开发分支 **例如：** 1，目前master tag版本为  maste\_tag\_v1.2.3 2，迭代启动确定此次开发版本为v1.2.4 3，开发拉取dev分支：dev\_20190820\_v1.2.4 4，提测后，从dev分支打tag分支：test\_tag\_v1.2.4.0交付测试进行sit测试，如测试有问题，修改dev分支后从新打test\_tag\_v1.2.4.1交付测试 5，sit完成后以最新测试tag分支test\_tag\_v1.2.4.1进行uat测试号，发现问题后返回第4步升级tag版本test\_tag\_v1.2.4.2，进行sit测试，再进行uat测试 6，uat完成后使用最新tag分支test\_tag\_v1.2.4.2进行上线，上线验证成功后合并master，打master\_tag\_v1.2.4 7，如果发现线上问题，需要修复，拉取hotfix\_20190821\_v1.2.4.1按照dev分支同样步骤进行紧急上线完成后打master\_tag\_v1.2.4.1 **老环境（目前情况）：** 开发分支 dev\_{时间戳}\_{业务名} 测试也用开发分支 生产合并release 测试比对版本回归后进行上线 线上验证完成合并master，其他正在进行的开发分支进行master合并 如果上生产后有线上紧急需要修复问题，从master拉取hotfix版本，同迭代分支步骤要求一致 **Jar****包管理规范：** **私有云&老环境：** DEV及SIT环境用SNAPSHOT进行开发测试，普通开发人员没有deploy  release的权限 UAT环境测试中用snapshot版本，稳定后使用release，如果release后有修改，需用snapshot验证无误后升级release版本号进行更新