Git工作流程讨论

查看:59
本文介绍了Git工作流程讨论的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

问 题

  看了几个git的工作流,感觉都不太符合自己目前的流程。目前我们有三个环境:生产环境、测试环境、本地环境。开发人员在本地开发,push到测试环境,测试人员就在测试环境测试 验收。

  目前我们只有十几个人的小团队,没有一个具体的版本发布流程,所以也没有到哪天发布什么版本,哪个任务在什么时间完成之类的,每个人的工作更像是在做hotfix,做完一个小功能或者修复一个小bug就直接推送到develop分支,任务指向测试人员去测试环境测试,没问题了 直接把develop合并到master,发布! 这个流程在人少的时候还可以,人稍微多一点,就牵扯到 我有个功能要上线了 而另一个功能还在测试阶段,master和develop没法合并,只能等测试结束...

  基于功能分支的模式,好像可以解决上述的问题,切一个分支做功能或者修复bug,合并到develop去测试,测试通过后合并到master,这时候master就可以随时推送到生产环境。但是另一个问题,团队里的成员水平参差不齐,不能让每个人都有权限合并到master,需要有人去review代码,也就是说,合并到master这个操作只能由一个人或几个人去操作而不是全部,然而可能每天产生的分支就有很多,小到修改一行文字可能都是一个分支,手工去合并这些小分支又是一个很大的工作量.这个跟提交pr的方式有点类似,不够高效...

  有什么方法能让测试人员及时看到你的修改方便测试 ,又能随时随地的!有选择性的!往生产环境合并代码?

解决方案

和我们的工作流很像,不过我们有规定具体什么时间出版本,出了版本开发人员再自己的分支上开发,然后在合并的时候想主管发merge-request,主管同意了就到develop分支,然后测试也测develop,测试完没问题再上主分支。

这篇关于Git工作流程讨论的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆