Git实战笔记(一) 常见错误

这篇文章将会记录一些在使用 Git 过程中经常会遇到的错误及其解决办法（持续更新）

---

错误 1

> git push
# fatal: unable to access 'https://github.com/xxx/xxx.git/': Failed to connect to github.com port 443: Timed out

【解决办法】

这种情况可能是网络波动引起的，可以尝试更换网络环境或者多试几次

错误 2

> git push
# fatal: repository 'https://github.com/xxx/xxx.git/' not found

【解决办法】

这种情况可能是权限验证错误引起的，可以尝试卸载 Git 凭证管理器后重装

> git credential-manager uninstall # 卸载

> git credential-manager install   # 安装

错误 3

> git push
# fatal: unable to access 'https://github.com/xxx/xxx.git/': OpenSSL SSL_read: Connection was reset, errno 10054

【解决办法】

这种情况可能是 SSL 验证失败导致的，我们可以直接禁止 SSL 验证

git config --global http.sslVerify "false"

官网上关于 http.sslVerify 的说明如下：

Whether to verify the SSL certificate when fetching or pushing over HTTPS. Defaults to true. Can be overridden by the GIT_SSL_NO_VERIFY environment variable.

通过 HTTPS 抓取和推送时是否进行 SSL 验证。默认为 true。可以通过环境变量 GIT_SSL_NO_VERIFY 进行重写。

错误 4

> git push
# Enumerating objects: 76, done.
# Counting objects: 100% (76/76), done.
# Delta compression using up to 4 threads
# Compressing objects: 100% (59/59), done.
# Writing objects: 100% (60/60), 808.06 MiB | 10.78 MiB/s, done.
# Total 60 (delta 32), reused 0 (delta 0), pack-reused 0
# error: RPC failed; curl 18 transfer closed with outstanding read data remaining
# send-pack: unexpected disconnect while reading sideband packet
# fatal: the remote end hung up unexpectedly
# Everything up-to-date

【解决办法】

• 这种情况有可能是缓存过小引起的，我们可以尝试增大缓存（缓存大小根据实际情况设置）

git config --global http.postBuffer 1048576000

# 单位为 Byte，如 1048576000B 就是 1G

http.postBuffer 实际上做了什么？Git 官网上有一段相关的说明：

Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.

使用 smart HTTP 协议向远程 post 数据时，缓存区的最大大小，单位为 byte。对大于这个缓存大小的请求，会使用 HTTP/1.1 和 Transfer-Encoding: chunked 避免在本地创建一个庞大的打包文件。默认为 1 MiB，对于大多数请求而言已经足够。

Note that raising this limit is only effective for disabling chunked transfer encoding and therefore should be used only where the remote server or a proxy only supports HTTP/1.0 or is noncompliant with the HTTP standard. Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes.

注意，提高这个限制只对禁用分块传输的编码有效，因此只应在远程服务或代理只支持 HTTP/1.0 或不符合 HTTP 标准的情况下使用。一般来说，提高这个限制对大多数推送问题不是一个有效的解决方案，但会大大增加内存消耗，因为即使对于小规模的推送也会分配整个缓冲区。

• 这种情况也可能是网络波动导致的，我们可以尝试取消相关的网络限制

git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 999999

http.lowSpeedLimit 和 http.lowSpeedTime 实际上做了什么？官网上有一段相关的说明：

If the HTTP transfer speed is less than http.lowSpeedLimit for longer than http.lowSpeedTime seconds, the transfer is aborted. Can be overridden by the GIT_HTTP_LOW_SPEED_LIMIT and GIT_HTTP_LOW_SPEED_TIME environment variables.

若 HTTP 传输速度小于 http.lowSpeedLimit 或传输时间大于 http.lowSpeedTime，那么该传输就会中断。可以通过环境变量 GIT_HTTP_LOW_SPEED_LIMIT 和 GIT_HTTP_LOW_SPEED_TIME 进行重写。

• 如果传输的文件实在太大，可以试试增大压缩率（压缩率大小根据实际情况设置）

git config --global core.compression 3

core.compression 实际上做了什么？官网上有一段相关的说明：

An integer -1…9, indicating a default compression level. -1 is the zlib default. 0 means no compression, and 1…9 are various speed/size tradeoffs, 9 being slowest. If set, this provides a default to other compression variables, such as core.looseCompression and pack.compression.

用一个整数 -1 … 9 表示压缩级别。-1 表示使用 zlib 默认值。0 意味着不压缩，1 … 9 是压缩速度/压缩大小的权衡，9 压缩速度最慢/压缩大小最小。如果这个值被设置，那么将会给其它压缩相关的变量提供一个默认值，例如 core.looseCompression 和 pack.compression。

• 如果有多次提交一起推送，可以试试分多次推送【重要】

git push <远程仓库名称> <commit id>:<远程分支名称>

# 这个命令会推送指定 <commit id> 前所有未推送的 commit