完美解决 git 报错 “fatal: unable to access ‘https://github.com/.../.git‘: Recv failure Connection was rese

完美解决 git 报错 “fatal: unable to access ‘https://github.com/.../.git‘: Recv failure Connection was rese

文章目录

🎉欢迎来到Java学习路线专栏~探索Java中的静态变量与实例变量☆* o(≧▽≦)o *☆嗨~我是IT·陈寒🍹✨博客主页:IT·陈寒的博客🎈该系列文章专栏:Java学习路线📜其他专栏:Java学习路线Java面试技巧Java实战项目AIGC人工智能数据结构学习🍹文章作者技术和水平有限,如果文中出现错误,希望大家能指正🙏📜 欢迎大家关注! ❤️

在使用 Git 进行代码管理的过程中,经常会遇到各种各样的问题,其中之一就是在执行 git clonegit pull 等操作时出现 “fatal: unable to access ‘https://github.com/…/.git’: Recv failure Connection was reset” 的报错。这个问题通常是由网络连接问题或代理设置不正确导致的。在我的个人使用经验中,我亲自尝试了两种方法,它们都能够有效地解决这个报错。

方法一:取消代理设置

这是最常见的解决方法之一,通过在终端执行以下命令,可以取消 Git 的代理设置:

git config --global--unset http.proxy git config --global--unset https.proxy 
在这里插入图片描述

这样就可以清除 Git 的代理设置,让其直接连接网络进行操作。

方法二:设置系统代理

有时候取消代理设置仍然会出现报错,这时可以通过设置系统代理来解决。具体步骤如下:

  1. 在终端输入以下命令,设置 Git 使用本地代理:

在代理服务器中,将端口设置为7890(这个端口不会影响正常上网,可以放心设置),然后点击保存。

在这里插入图片描述

打开系统设置,搜索代理设置,并点击编辑按钮。

在这里插入图片描述
git config --global http.proxy http://127.0.0.1:7890 

设置完成后,可以通过以下命令检验是否设置成功:

git config --global-l

结语

通过以上两种方法,我们可以有效地解决 “fatal: unable to access ‘https://github.com/…/.git’: Recv failure Connection was reset” 的报错问题。在使用 Git 过程中,遇到各种问题都是很正常的,但只要掌握了正确的解决方法,就能够顺利地进行代码管理和版本控制。愿你在使用 Git 时,能够顺利、愉快地完成工作!


🧸结尾 ❤️ 感谢您的支持和鼓励! 😊🙏
📜您可能感兴趣的内容:【Java面试技巧Java面试八股文 - 掌握面试必备知识(目录篇)Java学习路线2023年完整版Java学习路线图AIGC人工智能Chat GPT是什么,初学者怎么使用Chat GPT,需要注意些什么Java实战项目SpringBoot+SSM实战:打造高效便捷的企业级Java外卖订购系统数据结构学习从零起步:学习数据结构的完整路径

Read more

Spring Boot 视图层与模板引擎

Spring Boot 视图层与模板引擎

Spring Boot 视图层与模板引擎 19.1 学习目标与重点提示 学习目标:掌握Spring Boot视图层与模板引擎的核心概念与使用方法,包括Spring Boot视图层的基本方法、Spring Boot与Thymeleaf的集成、Spring Boot与Freemarker的集成、Spring Boot与Velocity的集成、Spring Boot的静态资源管理、Spring Boot的实际应用场景,学会在实际开发中处理视图层问题。 重点:Spring Boot视图层的基本方法、Spring Boot与Thymeleaf的集成、Spring Boot与Freemarker的集成、Spring Boot与Velocity的集成、Spring Boot的静态资源管理、Spring Boot的实际应用场景。 19.2 Spring Boot视图层概述 Spring Boot视图层是指使用Spring Boot进行Web应用开发的方法。 19.2.1 视图层的定义 定义:视图层是指使用Spring Boot进行Web应用开发的方法。 作用:

By Ne0inhk
70 倍性能碾压 + SQL 全兼容!金仓数据库终结 InfluxDB 的复杂时序场景统治

70 倍性能碾压 + SQL 全兼容!金仓数据库终结 InfluxDB 的复杂时序场景统治

70 倍性能碾压 + SQL 全兼容!金仓数据库终结 InfluxDB 的复杂时序场景统治 在物联网、工业互联网和运维监控领域,时序数据处理的需求正以前所未有的速度增长。面对海量设备产生的持续数据流,企业需要一个既能高速写入、又能快速分析的数据库引擎。长期以来,InfluxDB以其在时序领域的先发优势和简洁设计,成为许多团队的首选。然而,随着数据规模从“万级”跃升至“千万级”,业务查询从简单的点查变为复杂的多维度聚合,其性能瓶颈开始显现。 一场关于性能、扩展性与综合能力的较量,正在国产数据库金仓(KingbaseES)与国际开源方案InfluxDB之间展开。 性能对决:从数据摄入到复杂洞察的全面领先 真正的性能对比必须基于真实、可复现的测试场景。金仓数据库使用业界公认的开源时序基准测试套件TSBS,与InfluxDB进行了多轮正面较量,结论清晰而有力:在小规模、简单查询的工作负载下,两者各有千秋;但在大规模、复杂分析的真实生产环境中,金仓展现出压倒性的优势。 在数据写入吞吐方面,格局随数据规模急剧变化。测试模拟了从100台到1000万台设备的不同数据压力。当设备规模达到40

By Ne0inhk
数据库事务隔离级别与Spring传播行为深度解析

数据库事务隔离级别与Spring传播行为深度解析

干了多年Java开发,我可以明确告诉你:事务问题是线上最隐蔽的bug来源。很多人以为加了@Transactional就万事,结果数据不一致、死锁、性能问题接踵而至。今天咱们就彻底搞清楚事务隔离级别和传播行为这两个看似简单实则坑多的概念。 目录 🎯 先说说我被事务"坑惨"的经历 ✨ 摘要 1. 事务不是"要么全做,要么不做"那么简单 1.1 ACID原则的真相 1.2 事务的"不可能三角" 2. 四种隔离级别深度解析 2.1 并发问题三兄弟 2.2 隔离级别对比 2.3 MVCC:隔离级别的实现核心 3. 锁机制:事务隔离的基石 3.1 MySQL锁类型详解

By Ne0inhk
SQL 注入防不住?KS内核级防火墙,白名单防护零误报

SQL 注入防不住?KS内核级防火墙,白名单防护零误报

在数字化转型的浪潮中,数据已成为企业的核心资产。然而,SQL注入攻击如同潜伏在阴影中的“不速之客”,时刻威胁着数据库的安全。即使开发团队严守预编译、输入过滤等防线,遗留代码、第三方组件的漏洞或人为疏忽仍可能给攻击者可乘之机。难道只能被动挨打、疲于补漏吗? KingbaseES V009R002C014版本内置的SQL防火墙,给出了一种更聪明的答案——从数据库内核层构建主动防御,让恶意SQL无处遁形,安全团队从此告别“亡羊补牢”,真正实现“规则先行”。 一、SQL注入:那个偷偷溜进房子的“不速之客” SQL注入的原理并不复杂,却极其致命:攻击者将恶意代码伪装成正常输入,欺骗数据库执行非预期操作。 举个简单的例子:一个登录表单中,用户在用户名栏输入 ' OR '1'='1,后台的查询语句可能就变成了: SELECT * FROM users WHERE OR '1'='1&

By Ne0inhk