赞
踩
这篇文章分享 Git 分支设计规范,目的是提供给研发人员做参考。
规范是死的,人是活的,希望自己定的规范,不要被打脸。
在说 Git 分支规范之前,先说下在系统开发过程中常用的环境。
比如,项目域名为:http://www.abc.com
,那么相关环境的域名可这样配置:
http://fat.abc.com
http://uat.abc.com
http://www.abc.com
接下来,针对不同的环境来设计分支。
master
为主分支,用于部署到正式环境(PRO),一般由 release
或 hotfix
分支合并,任何情况下不允许直接在 master 分支上修改代码。
release
为预上线分支,用于部署到预上线环境(UAT),始终保持与 master
分支一致,一般由 develop
或 hotfix
分支合并,不建议直接在 release
分支上直接修改代码。
如果在 release
分支测试出问题,需要回归验证 develop
分支看否存在此问题。
hotfix
为紧急修复分支,命名规则为 hotfix-
开头。
当线上出现紧急问题需要马上修复时,需要基于 release
或 master
分支创建 hotfix
分支,修复完成后,再合并到 release
或 develop
分支,一旦修复上线,便将其删除。
develop
为测试分支,用于部署到测试环境(FAT),始终保持最新完成以及 bug 修复后的代码,可根据需求大小程度确定是由 feature
分支合并,还是直接在上面开发。
一定是满足测试的代码才能往上面合并或提交。
feature
为需求开发分支,命名规则为 feature-
开头,一旦该需求上线,便将其删除。
这么说可能有点不容易理解,接下来举几个开发场景。
有一个订单管理的新需求需要开发,首先要创建一个 feature-order
分支,问题来了,该分支是基于哪个分支创建?
如果 存在 未测试完毕的需求,就基于 master
创建。
如果 不存在 未测试完毕的需求,就基于 develop
创建。
feature-order
分支开发完毕,准备提测时,要先确定 develop
不存在未测试完毕的需求,这时研发人员才能将将代码合并到 develop
(测试环境)供测试人员测试。develop
(测试环境) 测试通过后,研发人员再将代码发布到 release
(预上线环境)供测试人员测试。release
(预上线环境)测试通过后,研发人员再将代码发布到 master
(正式环境)供测试人员测试。master
(正式环境) 测试通过后,研发人员需要删除 feature-order
分支。有一个订单管理的迭代需求,如果开发工时 < 1d,直接在 develop
开发,如果开发工时 > 1d,那就需要创建分支,在分支上开发。
开发后的提测上线流程 与 新需求加入的流程一致。
在 develop
测试出现了Bug,如果修复工时 < 2h,直接在 develop
修复,如果修复工时 > 2h,需要在分支上修复。
修复后的提测上线流程 与 新需求加入的流程一致。
在 release
测试出现了Bug,首先要回归下 develop
分支是否同样存在这个问题。
如果存在,修复流程 与 修复测试环境 Bug流程一致。
如果不存在,这种可能性比较少,大部分是数据兼容问题,环境配置问题等。
在 master
测试出现了Bug,首先要回归下 release
和 develop
分支是否同样存在这个问题。
如果存在,修复流程 与 修复测试环境 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
“挑拣”提交对于并行提测,你有好的方案吗?欢迎留言。
提交信息一定要认真填写!
建议参考规范:<type>(scope):<subject>
比如:fix(首页模块):修复弹窗 JS Bug。
type
表示 动作类型,可分为:
scope
表示 影响范围,可分为:模块、类库、方法等。
subject
表示 简短描述,最好不要超过 60 个字,如果有相关 Bug 的 Jira 号,建议在描述中加上。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。