【代码管理】在本地使用github和gitee之后,可能存在冲突,导致再次提交代码时提示Couldn‘t connect to server

【代码管理】在本地使用github和gitee之后,可能存在冲突,导致再次提交代码时提示Couldn‘t connect to server
大家好,我是全栈小5,欢迎来到《小5讲堂》。
这是《源代码管理工具》系列文章,每篇文章将以博主理解的角度展开讲解。
温馨提示:博主能力有限,理解水平有限,若有不对之处望指正!
在这里插入图片描述

目录

前言

最近在用github拉取代码,不知道什么情况下,导致两者出现冲突。
使用完毕github后,隔天再次推送gitee上面代码就提示无法连接到服务器了,
并且提示本地ip地址127.0.0.1,以及端口号7898

错误提示

git.exe clone --progress -v -- "https://gitee.com/xxx/xxx.git" "D:\github\xxx" Cloning into 'D:\github\xxx'... fatal: unable to access 'https://gitee.com/xxx/xxx.git/': Failed to connect to 127.0.0.1 port 7898 after 2116 ms: Couldn't connect to server git 未能顺利结束 (退出码 128) (2250 ms @ 2025/9/24 14:47:30) 

解决方案

这个问题是因为 Git 试图通过本地 7898 端口的代理服务器连接 Gitee,但代理服务没有运行。以下是几种解决方案:

方案1:临时关闭 Git 的代理设置(推荐先尝试)

# 取消全局代理设置git config --global --unset http.proxy git config --global --unset https.proxy # 或者只为 Gitee 域名取消代理【博主是通过执行下面方式就可以了】git config --global http.https://gitee.com.proxy ""git config --global https.https://gitee.com.proxy ""

方案2:检查并启动代理服务

如果您确实需要使用代理,请启动您的代理软件:

  • Clash/V2Ray:打开代理软件,确保它正在运行
  • 检查代理端口:确认代理软件确实使用 7898 端口

方案3:直接使用命令行取消代理后克隆

# 1. 先取消代理设置git config --global --unset http.proxy git config --global --unset https.proxy # 2. 重新克隆项目git clone https://gitee.com/xiao555/centerinfo.git "D:\github\centerinfo"

方案4:检查环境变量

有时候代理设置可能来自环境变量:

# 检查环境变量echo$HTTP_PROXYecho$HTTPS_PROXYecho$http_proxyecho$https_proxy# 如果设置了,可以临时取消setHTTP_PROXY=setHTTPS_PROXY=

针对 Windows 系统的具体操作

方法1:使用 Git Bash 或命令提示符

# 打开命令提示符或 Git Bash,依次执行:git config --global --unset http.proxy git config --global --unset https.proxy git clone https://gitee.com/xiao555/centerinfo.git "D:\github\centerinfo"

方法2:检查全局 Git 配置

# 查看当前 Git 配置git config --global --list # 如果看到 proxy 设置,就取消它

验证解决方案

执行完上述命令后,重新运行克隆命令:

git clone https://gitee.com/xiao555/centerinfo.git "D:\github\centerinfo"

如果您确实需要代理

如果您的网络环境必须使用代理,请:

  1. 确保代理软件正常运行
  2. 确认代理端口确实是 7898
  3. 或者将 Git 配置为使用正确的代理地址

为什么会冲突

GitHub 和 Gitee 本身不会冲突,但在使用过程中可能会出现以下几种"冲突"情况:

1. 代理配置冲突

问题原因:

  • GitHub:国外网站,通常需要代理才能快速访问
  • Gitee:国内网站,直连速度更快,走代理反而慢或无法连接

典型症状:

# 为 GitHub 设置了代理,但 Gitee 也走代理导致失败git config --global http.proxy http://127.0.0.1:7898 git config --global https.proxy http://127.0.0.1:7898 

2. 认证信息冲突

SSH 密钥冲突:

# 同一个 SSH 密钥可能在不同平台权限不同# GitHub 和 Gitee 可能使用相同的 SSH 密钥,但配置不同

账号认证冲突:

  • 缓存了错误的凭据
  • 两个平台使用不同的用户名/邮箱

3. 解决方案

方案1:为不同平台设置不同的代理规则

# 只为 GitHub 设置代理git config --global http.https://github.com.proxy http://127.0.0.1:7898 git config --global https.https://github.com.proxy http://127.0.0.1:7898 # Gitee 直连(取消代理)git config --global http.https://gitee.com.proxy ""git config --global https.https://gitee.com.proxy ""

方案2:使用代理软件的规则模式

在代理软件(Clash/V2Ray)中设置:

  • GitHub 走代理
  • Gitee 直连(DIRECT)

方案3:分开配置不同的远程仓库

# 为特定仓库设置单独配置cd /path/to/gitee-project git config http.proxy ""# Gitee 项目直连cd /path/to/github-project git config http.proxy http://127.0.0.1:7898 # GitHub 项目走代理

方案4:使用 SSH 替代 HTTPS

# 使用 SSH 连接可以避免 HTTP/HTTPS 代理问题git clone [email protected]:xiao555/centerinfo.git git clone [email protected]:username/repo.git 

4. 凭据管理冲突解决

检查当前配置:

# 查看所有 Git 配置git config --global --list # 查看特定配置git config --global http.proxy git config --global https.proxy 

清理缓存凭据:

# Windows 凭据管理器清理# 或使用 Git 命令清理git credential-manager reject https://gitee.com git credential-manager reject https://github.com 

5. 推荐的最佳实践

配置示例:

# 取消全局代理git config --global --unset http.proxy git config --global --unset https.proxy # 按需为国外网站设置代理git config --global http.https://github.com.proxy http://127.0.0.1:7898 git config --global http.https://gitlab.com.proxy http://127.0.0.1:7898 # 国内网站直连git config --global http.https://gitee.com.proxy ""

6. 验证配置是否正确

# 测试 Gitee 连接(应该直连)git ls-remote https://gitee.com/xiao555/centerinfo.git # 测试 GitHub 连接(应该走代理)git ls-remote https://github.com/someuser/somerepo.git 

文章推荐

【代码管理】在本地使用github和gitee之后,可能存在冲突,导致再次提交代码时提示Couldn’t connect to server

【代码管理】使用github在线源代码管理工具时,遇到443提示服务器无法连接到

【Git】查看凭据管理器的账号信息,并删除账号,解决首次认证登录失败后无法重新登录的问题

总结:温故而知新,不同阶段重温知识点,会有不一样的认识和理解,博主将巩固一遍知识点,并以实践方式和大家分享,若能有所帮助和收获,这将是博主最大的创作动力和荣幸。也期待认识更多优秀新老博主。

Read more

通过GitHub Projects管理ms-swift开发路线图

通过 GitHub Projects 管理 ms-swift 开发路线图 在大模型技术飞速演进的今天,一个关键问题日益凸显:如何将前沿算法快速、稳定地转化为可落地的生产系统?研究团队常常面临这样的困境——训练脚本写了一堆,部署流程各自为政,多模态支持零散拼凑,最终导致迭代缓慢、协作困难。尤其当项目涉及数百种异构模型和多种硬件平台时,缺乏统一工程框架的成本会被急剧放大。 魔搭社区推出的 ms-swift 正是为解决这一难题而生。它不仅是一个微调与部署工具包,更是一套面向生产环境的大模型工程基础设施。从预训练到量化推理,从文本模型到多模态系统,ms-swift 提供了全链路标准化能力。更重要的是,这样一个复杂系统的持续演进,并非依赖少数核心开发者推动,而是通过 GitHub Projects 实现透明化、社区化的路线图管理。 这种“开源 + 敏捷看板”的组合,让功能规划不再藏于内部会议纪要中,而是公开可见、可参与、可追踪。每一个新特性、每一次优化,都以卡片形式展现在项目面板上,关联具体的 issue、PR 和里程碑。

By Ne0inhk
【QQ机器人】简易部署,仅使用官方开源python代码,无需外部框架接入

【QQ机器人】简易部署,仅使用官方开源python代码,无需外部框架接入

官方最近对使用AIGC接口的机器人进行了封禁,且以往的WebSocket服务将陆续不再支持,故本文旨在以最为基础的办法,不使用外部框架,利用Webhook方式接入机器人 准备工作 前往QQ开放平台注册机器人账号 沙箱配置 在“沙箱配置”中配置用于机器人测试的群聊、私聊账号以及频道信息 开发管理 在“开发管理”中可以看到机器人的ID、密钥等信息,很重要,后续需要使用。IP白名单中需要放行你的服务器公网IP 回调配置 在“回调配置”中需要配置Webhook服务使用的回调地址,需要准备一个已备案的域名,并且域名需要解析到你的公网IP上。同时,域名需要部署SSL证书(能用https访问)。 可以仿照我的后缀写,后续配置Webhook时需要使用 你的域名/qqbot-webhook/callback 填写好此时会提示“校验失败”,不用着急,因为Webhook服务还没有启用,过一会儿会回来重填 篇幅原因,不介绍服务器租用、公网购买、证书部署等相关的知识,网上有文章很多可自查 添加事件省事建议全选,也可以自选需要的,选好后需要在右下角确认配置 阿里云的免费SSL个人测试

By Ne0inhk

Qwen2.5-7B与Gemini对比:开源vs闭源模型部署成本分析

Qwen2.5-7B与Gemini对比:开源vs闭源模型部署成本分析 1. 技术背景与选型动因 随着大语言模型(LLM)在自然语言理解、代码生成、多轮对话等场景的广泛应用,企业在构建AI能力时面临一个关键决策:选择开源模型自建部署,还是采用闭源API服务?这一选择直接影响到系统的可控性、数据隐私、响应延迟以及长期运营成本。 阿里云近期发布的 Qwen2.5-7B 是一款典型的高性能开源大模型,支持高达128K上下文长度和结构化输出,在中文场景下表现尤为突出。而 Google 的 Gemini Pro 则代表了主流闭源大模型的服务模式,提供稳定API、多模态能力和全球基础设施支持。 本文将从部署架构、硬件需求、推理成本、可扩展性与维护复杂度五个维度,深入对比 Qwen2.5-7B(开源)与 Gemini(闭源)的实际落地差异,并结合真实部署案例,帮助技术团队做出更合理的选型决策。 2. 方案A:Qwen2.5-7B —— 开源模型的本地化部署实践 2.

By Ne0inhk
别只用ChatGPT!2026年这5个开源AI工具才是程序员的真正利器

别只用ChatGPT!2026年这5个开源AI工具才是程序员的真正利器

文章目录 * 前言 * 一、 Ollama v0.14.3 本地大模型天花板,新增图像生成直接封神 * 实操代码(新手直接复制) * 核心亮点 * 二、 Stable Diffusion XL 1.0 开源生图卷王,直逼Midjourney * 实操代码(本地部署极简版) * 核心亮点 * 三、 LangChain 1.0 智能体开发神器,重构后封神级好用 * 实操代码(快速搭建智能体) * 核心亮点 * 四、 AIMatrices DeepSeek 轻量级本地化部署神器,40M体积秒启动 * 实操代码(一键部署+调用) * 核心亮点 * 五、 BuildingAI 零代码搭建AI智能体,开源可商用,还能变现 * 实操步骤(附核心代码) * 核心亮点 * 写在最后

By Ne0inhk