這篇文章將會記錄一些在使用 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_VERIFYenvironment 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