我所做的:我在Github上创建了一个远程存储库,我试图在我的本地机器上克隆远程存储库。克隆时,我提供克隆URL和目标文件夹。
但每次我尝试克隆,我得到这个错误:
错误:“致命:无法访问https://github.com/hyperion057/spring-repo.git/':无法解决主机:github.com”
我需要做什么才能连接到GitHub ?
我所做的:我在Github上创建了一个远程存储库,我试图在我的本地机器上克隆远程存储库。克隆时,我提供克隆URL和目标文件夹。
但每次我尝试克隆,我得到这个错误:
错误:“致命:无法访问https://github.com/hyperion057/spring-repo.git/':无法解决主机:github.com”
我需要做什么才能连接到GitHub ?
当前回答
在我的情况下(这是一个私人的git回购),主机被挂起,所以问题是我的GitHub服务器和管理员解决了它。
其他回答
我需要配置代理设置吗?因为我办公室有代理服务器。
是的,您可以通过设置HTTP_PROXY和HTTPS_PROXY环境变量来做到这一点。
参见“同步与github”:
set HTTPS_PROXY=http://<login_internet>:<password_internet>@aproxy:aport
set HTTP_PROXY=http://<login_internet>:<password_internet>@aproxy:aport
set NO_PROXY=localhost,my.company
(为了避免在代理URL中明确放置您的凭据—用户名/密码,请参见下文)
注意NO_PROXY,允许访问您公司的内部站点
你也可以在你的git配置中注册:
git config --global http.proxy http://<login_internet>:<password_internet>@aproxy:aport
但是如果你有不正确的代理Git设置,请删除它们:
cd /path/to/repo
git config --unset http.proxy
git config --global --unset http.proxy
git config --system --unset http.proxy
git config --unset https.proxy
git config --global --unset https.proxy
git config --system --unset https.proxy
# double-check with:
git config -l --show-origin | grep -i proxy
不需要凭证:使用genotrance/px。 如果你像我一样,在一个NTLM代理背后的公司,你所需要做的就是:
解压缩px-v0.4.0.zip到任何你想要的地方 更改px.ini配置文件(把它放在%USERPROFILE%),更改服务器行: (代理) Server = proxy.my.company:8080 <=使用您公司的proxy:port Listen = 127.0.0.1 端口= 3128 使用HTTP(S)代理变量没有您的凭据!(px代理将通过Microsoft SSPI或Microsoft Kerberos重用当前寡妇会话中的文件)
这将给你:
set HTTPS_PROXY=http://127.0.0.1:3128
set HTTP_PROXY=http://127.0.0.1:3128
set NO_PROXY=localhost,my.company
另一种可能是,我自己也遇到了这个问题。但那是在我安装了一个VPN之后(这是不相关的,正在运行)
关闭VPN,修复了这个问题。
声明一下,我在我的MacBookPro上运行“粘度”VPN
这个问题的一个原因可能是错误的/空的/etc/resolv.conf文件。
我在我的centos 7 minimal中解决这个问题的方法如下: 我的/etc/resolv.conf是空的,我添加了以下几行:
nameserver 192.168.1.1
nameserver 0.0.0.0
192.168.1.1是我的网关,在您的情况下,它可以是不同的。
我用这个命令解决了它
$git config --global http.proxy http://enter_your_proxy:enter_port
在我的例子中,在Windows机器上,我的TCP/IP堆栈似乎需要重置。重置客户端PC的TCP/IP堆栈导致git重新开始正常工作。在管理员模式下在命令提示符下执行该命令,然后重试git命令:
netsh int ip reset
通过Control Panel手动禁用和重新启用网络适配器也会产生类似的结果。
我怀疑在我的Windows机器上的TCP堆栈内部存在DNS解析问题。