本文转载自微信公众号「虞大胆的叽叽喳喳」,作者虞大胆 。转载本文请联系虞大胆的叽叽喳喳公众号。
在基于git的工作流中,master一般是做持续集成的,开发人员在特性分支开发,经过测试后,就会merge到master做集成测试,测试通过就表示master可部署了。
可现实情况下,特性分支自测没问题,不代表就真的没问题,测试人员还没测试呢,所以此时的master分支其实是没准备好的(从master特定commit id到生成分支其实是有一定难度的)
我们目前的做法,在master分支之前还有一个SIT系统集成分支,也就是说这个分支是专门给QA人员测试的,测试没问题后,将特性分支的代码合并到pre分支,仿真环境如果没问题,再将特性分支合并到master分支,然后进行发布。
SIT分支相当于做集成测试了,保证了master的代码是相对可靠的。
那什么代码合并到SIT分支呢?不管几个项目,也不管这些项目具体的上线时间,特性分支都可以合并到SIT分支,然后统一给QA人员测试(相当于提前测试多个项目了),正因为这样,上线的时候无法从SIT分支merge到master分支。
这种工作流多了一个步骤,必然会有副作用,首先merge到SIT分支的时候,如果有冲突,SIT分支不应该解决冲突,因为SIT分支只是为了测试,不会上线的,所以不应该解决冲突;其次很多人说为了避免有冲突,那么我就经常性的将SIT分支上的代码merge(也就是pull)到特性分支,这也非常不好,因为这个特性分支就不隔离了。所以正确的做法,如果merge到SIT分支产生冲突,应该自己去解决冲突,可如何找到和那个分支冲突呢?
还有SIT分支和master分支因为时间点和作用不一样,没有必要保持代码是同步,可pre分支和master分支理论上应该保持同步,上线的时候没有选择merge SIT分支到master分支的原因是cherry-pick还是有一定复杂度的,merge特定commit id也是有复杂度的,所以我们选择从特性分支合并到master,那必然要思考一个问题,pre分支测试通过代表master分支测试通过吗?如果pre到master是一个fast forward,理论上不用再重复测试。
还有一种做法和我们的做法类似,就是有一个隐形的SIT分支,特性分支一旦提交到远端,就自动merge到SIT分支,查看是否有冲突,如果有冲突,就提醒开发者去解决,从而保障能够持续集成。
最后说说特性分支,我们还喜欢根据迭代周期去弄一个大分支,实际上这个大分支包含了很多子功能,也就是说可以拆分为多个子分支,那这两种方式有什么优缺点呢?
如果在一个大分支,能够减少一些冲突,但做不到隔离了,如果频繁的pull,是选择merge还是rebase呢?应该选择merge,推送到远端的分支不建议做rebase,会产生很多问题。其实既然选择了一个大分支,那git历史记录必然会很难看的,基本没有追朔性。如果实在要使用一个大分支,建议不要太频繁的提交到远端,尽量做好自测再提交。SIT部署的环境(QA)是为了测试人员测试的,应该保障一定的稳定性,它们不是给开发人员调试用的。
建议还是子分支,一方面说不定有一天就上线部分功能,子分支就合适了;另外子分支也能做到隔离;当然可能会遇到很多merge冲突的问题,这时候就需要自己甄别与那个分支发生冲突了(目前没有想到办法)。
git工作流有多种选择,主要看整个团队对git的理解程度,并行项目数量,CI/CD方式等等,没有绝对的好坏,只要能说得通,没有明显的缺点,那就是好的工作流。
软件工程中 系统上线之后 仍需要持续对系统进行优化或者重构。 学会对应用系统进...
前言 大家好,我是Java进阶者。这篇文章我们主要介绍Java基础中的Object类、匿名...
linux系统 重要文件不小心给误删除了?怎么办?还能恢复吗?用什么办法恢复linux...
如何购买不用实名的 域名 ?如果不想实名,尽量避开需要实名的域名再注册。如果...
项目背景 目前 Web 的 TRTC 没有静音检测,在关闭麦克风的情况下发言没有提示,...
日前,全球效果导向移动营销平台 Nativex 正式通过欧洲知名第三方认证机构 ePriv...
作者 | 涌月 随着Nacos2.0成熟稳定 Nacos-spring-boot发布0.1.10、0.2.10两个核...
在开发前端时,我们经常使用AJAX来初始化数据并动态渲染在页面上,但是在遇到一...
本文转载自微信公众号「全栈码农画像」,作者小码甲 。转载本文请联系全栈码农画...
TOP云 (west.cn)12月1日消息,刚刚我们报道了两字母 域名 DO.COM由国外经纪公...