智能网站建设平台,如何设计响应式布局网站,承德网站制作加盟,域名注册阿里开篇
这篇文章分享 Git 分支设计规范#xff0c;目的是提供给研发人员做参考。
规范是死的#xff0c;人是活的#xff0c;希望自己定的规范#xff0c;不要被打脸。
在说 Git 分支规范之前#xff0c;先说下在系统开发过程中常用的环境。 DEV 环境#xff1a;用于开发…开篇
这篇文章分享 Git 分支设计规范目的是提供给研发人员做参考。
规范是死的人是活的希望自己定的规范不要被打脸。
在说 Git 分支规范之前先说下在系统开发过程中常用的环境。 DEV 环境用于开发者调试使用。FAT 环境功能验收测试环境用于测试环境下的软件测试者测试使用。UAT 环境用户验收测试环境用于生产环境下的软件测试者测试使用。PRO 环境就是生产环境。
比如项目域名为http://www.abc.com那么相关环境的域名可这样配置
DEV 环境本地配置虚拟域名即可FAT 环境http://fat.abc.comUAT 环境http://uat.abc.comPRO 环境http://www.abc.com
接下来针对不同的环境来设计分支。
分支 master 分支
master 为主分支用于部署到正式环境PRO一般由 release 或 hotfix 分支合并任何情况下不允许直接在 master 分支上修改代码。
release 分支
release 为预上线分支用于部署到预上线环境UAT始终保持与 master 分支一致一般由 develop 或 hotfix 分支合并不建议直接在 release 分支上直接修改代码。
如果在 release 分支测试出问题需要回归验证 develop 分支看否存在此问题。
hotfix 分支
hotfix 为紧急修复分支命名规则为 hotfix- 开头。
当线上出现紧急问题需要马上修复时需要基于 release 或 master 分支创建 hotfix 分支修复完成后再合并到 release 或 develop 分支一旦修复上线便将其删除。
develop 分支
develop 为测试分支用于部署到测试环境FAT始终保持最新完成以及 bug 修复后的代码可根据需求大小程度确定是由 feature 分支合并还是直接在上面开发。
一定是满足测试的代码才能往上面合并或提交。
feature 分支
feature 为需求开发分支命名规则为 feature- 开头一旦该需求上线便将其删除。
这么说可能有点不容易理解接下来举几个开发场景。
开发场景
新需求加入
有一个订单管理的新需求需要开发首先要创建一个 feature-order 分支问题来了该分支是基于哪个分支创建
如果 存在 未测试完毕的需求就基于 master 创建。
如果 不存在 未测试完毕的需求就基于 develop 创建。
需求在 feature-order 分支开发完毕准备提测时要先确定 develop 不存在未测试完毕的需求这时研发人员才能将将代码合并到 develop 测试环境供测试人员测试。测试人员在 develop 测试环境 测试通过后研发人员再将代码发布到 release 预上线环境供测试人员测试。测试人员在 release 预上线环境测试通过后研发人员再将代码发布到 master 正式环境供测试人员测试。测试人员在 master (正式环境) 测试通过后研发人员需要删除 feature-order 分支。
普通迭代
有一个订单管理的迭代需求如果开发工时 1d直接在 develop 开发如果开发工时 1d那就需要创建分支在分支上开发。
开发后的提测上线流程 与 新需求加入的流程一致。
修复测试环境 Bug
在 develop 测试出现了Bug如果修复工时 2h直接在 develop 修复如果修复工时 2h需要在分支上修复。
修复后的提测上线流程 与 新需求加入的流程一致。
修改预上线环境 Bug
在 release 测试出现了Bug首先要回归下 develop 分支是否同样存在这个问题。
如果存在修复流程 与 修复测试环境 Bug流程一致。
如果不存在这种可能性比较少大部分是数据兼容问题环境配置问题等。
修改正式环境 Bug
在 master 测试出现了Bug首先要回归下 release 和 develop 分支是否同样存在这个问题。
如果存在修复流程 与 修复测试环境 Bug流程一致。
如果不存在这种可能性也比较少大部分是数据兼容问题环境配置问题等。
紧急修复正式环境 Bug
需求在测试环节未测试出 Bug上线运行一段时候后出现了 Bug需要紧急修复的。
我个人理解紧急修复的意思是没时间验证测试环境了但还是建议验证下预上线环境。
如果 release 分支存在未测试完毕的需求就基于 master 创建 hotfix-xxx 分支修复完毕后发布到 master 验证验证完毕后将 master 代码合并到 release 和 develop 分支同时删掉 hotfix-xxx 分支。如果 release 分支不存在未测试完毕的需求但 develop 分支存在未测试完毕的需求就基于 release 创建 hotfix-xxx 分支修复完毕后发布到 release 验证后面流程与上线流程一致验证完毕后将 master 代码合并到 develop 分支同时删掉 hotfix-xxx 分支。如果 release 和 develop 分支都不存在未测试完毕的需求 就直接在 develop 分支上修复完毕后发布到 release 验证后面流程与上线流程一致。
并行提测
在一个项目中并行开发了两个需求并行提测但是上线日期不同。
我能想到的两种方案
再部署一套可供测试人员测试的分支使用 git cherry-pick “挑拣”提交
对于并行提测你有好的方案吗欢迎留言。
Commit 日志规范
提交信息一定要认真填写
建议参考规范type(scope)subject
比如fix(首页模块)修复弹窗 JS Bug。
type 表示 动作类型可分为
fix修复 xxx Bugfeat新增 xxx 功能test调试 xxx 功能style变更 xxx 代码格式或注释docs变更 xxx 文档refactor重构 xxx 功能或方法
scope 表示 影响范围可分为模块、类库、方法等。
subject 表示 简短描述最好不要超过 60 个字如果有相关 Bug 的 Jira 号建议在描述中加上。
