第13章：网络优化 —— 中国用户的必修课 ⭐

第13章：网络优化 —— 中国用户的必修课 ⭐

如果你在中国使用GitHub，这一章就是为你量身定制的救命稻草！相信你一定经历过这样的绝望时刻：凌晨三点，你终于写完了代码，兴奋地输入 git push，然后…进度条卡住了。一分钟、两分钟、五分钟…最后"Connection timeout"。这一刻，你想砸键盘、想摔鼠标、想对着屏幕怒吼。别慌，这不是你的错，是"国际带宽"的锅！

13.1 为什么 GitHub 这么慢？国际带宽的忧伤

什么是国际带宽？

国际带宽（International Bandwidth）是指中国与其他国家之间的网络连接通道。简单来说，就是访问国外网站时要走的"跨国高速公路"。

想象一下：你在北京，GitHub的服务器在旧金山。你的数据要跨越太平洋，经过海底光缆，穿过无数个路由器，才能到达目的地。这段路程，比从北京到上海远多了！

你的电脑（北京）
    ↓
国内网络（光速）
    ↓
国际出口（瓶颈！拥堵！）
    ↓
海底光缆（跨太平洋）
    ↓
美国网络
    ↓
GitHub服务器（旧金山）

为什么国际带宽是瓶颈？

1. 物理距离：光也要时间

即使是光速，从北京到旧金山也要几十毫秒。往返一次（RTT）就要100多毫秒。这意味着，每次你和GitHub服务器"握手"，都要等这么久。

2. 带宽有限：高速公路也会堵车

国际出口带宽是有限的。当太多人同时访问国外网站时，就像高速公路堵车一样，速度会急剧下降。晚上8点到12点是高峰期，GitHub慢得像蜗牛。

3. 网络审查：安全检查需要时间

为了网络安全，国际流量需要经过审查。这就像出国要经过海关检查，虽然必要，但确实会增加延迟。

4. DNS污染：被带错路的痛苦

有时候，GitHub的域名会被错误解析到错误的IP地址，导致你连不上或者连到很慢的服务器。这就像你要去故宫，却被导航带到了郊区。

GitHub慢的常见表现

测速：诊断你的网络

在解决问题之前，先诊断一下你的网络状况：

1. ping测试：看看延迟多少

1
2
3
4
5

# Windows
$ ping github.com

# Linux/Mac
$ ping -c 10 github.com

正常情况延迟应该在200ms以内，如果超过500ms，说明网络状况不好。

2. traceroute：看看路由路径

1
2
3
4
5

# Windows
$ tracert github.com

# Linux/Mac
$ traceroute github.com

这个命令会显示数据包经过的每一个节点，可以看到在哪里卡住了。

3. 测试下载速度

1
2

# 克隆一个大仓库测试
$ time git clone https://github.com/torvalds/linux.git

如果速度低于100KB/s，说明需要优化了。

解决思路概览

既然知道了问题所在，解决方案也就清晰了：

接下来的小节，我们将逐一深入学习这些优化技巧，让你的GitHub体验从"龟速"变"神速"！

13.2 代理配置：让 Git 走代理的几种姿势

使用代理是解决GitHub慢的最直接、最有效的方法。代理服务器在国外（或者香港、日本等网络好的地方），它帮你访问GitHub，然后把数据传回给你。就像你请了一个在国外的朋友帮你买东西，然后寄回来。

代理的工作原理

┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│   你的电脑   │ ──────▶ │  代理服务器  │ ──────▶ │  GitHub     │
│  （北京）   │         │ （香港/日本）│         │ （旧金山）   │
│             │ ◀────── │             │ ◀────── │             │
└─────────────┘  快速   └─────────────┘  快速   └─────────────┘
                      
     慢 ❌                    快 ✅                  快 ✅
     直接访问                 通过代理              代理到GitHub

配置HTTP代理

如果你使用的是HTTP代理（如Shadowsocks的HTTP模式、V2Ray的HTTP模式）：

全局配置（所有仓库都走代理）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 设置HTTP代理
# 127.0.0.1:1080 是代理地址，根据你的代理软件修改
$ git config --global http.proxy http://127.0.0.1:1080
$ git config --global https.proxy http://127.0.0.1:1080

# 查看配置是否生效
$ git config --global --get http.proxy
# 输出：http://127.0.0.1:1080

$ git config --global --get https.proxy
# 输出：http://127.0.0.1:1080

# 取消代理（当你不需要时）
$ git config --global --unset http.proxy
$ git config --global --unset https.proxy

仅对GitHub生效（推荐）：

1
2
3
4
5
6
7

# 只对github.com使用代理，其他网站不走代理
# 这样可以节省代理流量，也避免影响其他网站
$ git config --global http.https://github.com.proxy http://127.0.0.1:1080
$ git config --global https.https://github.com.proxy http://127.0.0.1:1080

# 查看配置
$ git config --global --get http.https://github.com.proxy

配置SOCKS5代理

如果你使用的是SOCKS5代理（Shadowsocks、V2Ray默认模式、Clash等）：

1
2
3
4
5
6
7

# Git 2.11+ 版本支持SOCKS5代理
# 注意：SOCKS5代理不需要用户名密码时这样配置
$ git config --global http.proxy socks5://127.0.0.1:1080
$ git config --global https.proxy socks5://127.0.0.1:1080

# 如果SOCKS5代理需要认证（有用户名密码）
$ git config --global http.proxy socks5://用户名:密码@127.0.0.1:1080

配置SSH走代理

SSH方式需要额外配置，因为SSH使用22端口，不走HTTP代理。

方法1：使用nc（netcat）—— 适用于Linux/Mac

编辑或创建 ~/.ssh/config 文件：

# ~/.ssh/config
# 这个配置让SSH连接GitHub时走SOCKS5代理

Host github.com
    HostName github.com
    User git
    # 使用nc命令通过SOCKS5代理连接
    ProxyCommand nc -v -x 127.0.0.1:1080 %h %p
    IdentityFile ~/.ssh/id_ed25519
    # %h 代表目标主机名(github.com)
    # %p 代表目标端口(22)
    # -x 指定SOCKS5代理地址

# 如果使用HTTP代理而不是SOCKS5
Host github.com
    HostName github.com
    User git
    ProxyCommand nc -v -X connect -x 127.0.0.1:1080 %h %p
    IdentityFile ~/.ssh/id_ed25519
    # -X connect 表示使用HTTP CONNECT方法

方法2：使用connect——适用于Windows

Windows上可以使用connect.exe工具：

# ~/.ssh/config
Host github.com
    HostName github.com
    User git
    ProxyCommand connect -S 127.0.0.1:1080 %h %p
    IdentityFile ~/.ssh/id_ed25519
    # -S 表示使用SOCKS5代理
    # 如果是HTTP代理，用 -H 参数

方法3：使用PuTTY（Windows图形界面）

如果你使用PuTTY管理SSH密钥：

1. 打开PuTTY
2. 选择你的GitHub会话配置
3. 左侧菜单：Connection → Proxy
4. 选择代理类型（HTTP或SOCKS5）
5. 填写代理地址和端口
6. 保存配置

验证代理是否生效

配置完成后，验证代理是否工作：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 1. 查看当前Git配置
$ git config --global --list | grep proxy
http.proxy=http://127.0.0.1:1080
https.proxy=http://127.0.0.1:1080

# 2. 测试clone速度
$ time git clone https://github.com/facebook/react.git temp-test

# 3. 对比：取消代理后再测试
$ git config --global --unset http.proxy
$ git config --global --unset https.proxy
$ time git clone https://github.com/facebook/react.git temp-test2

# 4. 清理测试文件
$ rm -rf temp-test temp-test2

代理配置速查表

常见问题

Q: 配置了代理还是慢？

A: 检查以下几点：

1. 代理软件是否正常运行
2. 代理地址和端口是否正确
3. 代理服务器本身是否快（尝试访问其他国外网站）
4. 是否配置了正确的代理类型（HTTP vs SOCKS5）

Q: 代理配置后其他网站访问变慢了？

A: 使用"仅对GitHub生效"的配置，或者只在需要时开启代理。

Q: 公司网络有防火墙，代理连不上？

A: 尝试使用443端口的代理（HTTPS端口通常开放），或者使用公司的代理服务器。

小结

代理是解决GitHub慢的最有效方法：

• HTTP/HTTPS代理配置简单，适合初学者
• SOCKS5代理更安全，适合Shadowsocks/V2Ray用户
• SSH代理需要额外配置，但一劳永逸
• 建议"仅对GitHub生效"，避免影响其他网站

配置好代理后，你的GitHub体验会有质的飞跃！

下一节，我们来比较SSH和HTTPS哪个更好。

13.3 SSH vs HTTPS：哪个更快更稳？

Git支持两种协议连接远程仓库：SSH和HTTPS。在中国网络环境下，哪个更好？这一节我们来深入对比分析。

SSH和HTTPS是什么？

SSH（Secure Shell）：

• 一种加密的网络传输协议
• 使用22端口
• 通过密钥对认证（私钥+公钥）
• 主要用于远程登录，也用于Git

HTTPS（HyperText Transfer Protocol Secure）：

• 安全的HTTP协议
• 使用443端口
• 通过用户名密码或Token认证
• 网页浏览的标准协议

SSH vs HTTPS 详细对比

为什么SSH在中国更快？

1. 协议效率更高

SSH协议本身比HTTPS更轻量。SSH设计用于远程登录，握手过程更简洁。HTTPS为了网页浏览设计，每次请求都有较多开销。

2. 22端口相对"干净"

• SSH使用22端口，这个端口主要用于服务器管理，流量相对较少
• HTTPS使用443端口，是所有网页浏览的流量，非常拥堵
• 虽然22端口有时会被限制，但一旦被允许通过，速度通常更快

3. 连接复用

SSH连接可以复用，一次认证后多次使用。HTTPS每次请求都要重新建立连接（虽然HTTP/2有所改善）。

4. 传输效率

Git over SSH使用专门的Git协议，传输效率更高。Git over HTTPS需要额外的HTTP头部开销。

实测对比

让我们实际测试一下SSH和HTTPS的速度差异：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 先确保两种协议都配置了

# 测试HTTPS速度
$ time git clone https://github.com/torvalds/linux.git temp-https
# 记录时间...

# 删除
$ rm -rf temp-https

# 测试SSH速度
$ time git clone git@github.com:torvalds/linux.git temp-ssh
# 记录时间...

# 删除
$ rm -rf temp-ssh

在中国网络环境下，SSH通常比HTTPS快2-5倍！

推荐使用SSH

在中国网络环境下，强烈建议使用SSH：

配置步骤：

1. 生成SSH密钥（如果还没有）

   1	$ ssh-keygen -t ed25519 -C "your_email@example.com"

2. 添加公钥到GitHub

   1 2	$ cat ~/.ssh/id_ed25519.pub # 复制内容到GitHub → Settings → SSH and GPG keys

3. 测试连接

   1 2	$ ssh -T git@github.com # 看到 "Hi username!" 表示成功

4. 使用SSH地址克隆

   1 2 3 4 5

   # 原HTTPS地址 https://github.com/username/repo.git # 改为SSH地址 git@github.com:username/repo.git

5. 修改已有仓库的远程地址

   1	$ git remote set-url origin git@github.com:username/repo.git

HTTPS的替代方案

如果由于某些原因只能用HTTPS（比如公司防火墙限制），可以：

1. 使用Personal Access Token（PAT）代替密码

GitHub在2021年后不再支持密码登录，必须使用Token：

1
2
3
4

# 克隆时输入Token作为密码
$ git clone https://github.com/username/repo.git
Username: your-username
Password: your-personal-access-token

2. 配置凭据缓存

避免每次都输入Token：

1
2
3
4
5
6
7
8

# 缓存凭据15分钟
$ git config --global credential.helper cache

# 或者永久存储（注意安全）
$ git config --global credential.helper store

# Windows使用凭据管理器
$ git config --global credential.helper manager

3. 使用代理加速HTTPS

见13.2节的代理配置。

特殊情况：SSH被防火墙阻止

有些公司防火墙会阻止22端口，这时候：

方案1：使用HTTPS+代理

1
2

$ git config --global http.proxy http://127.0.0.1:1080
$ git clone https://github.com/username/repo.git

方案2：SSH使用443端口

编辑 ~/.ssh/config：

Host github.com
    HostName ssh.github.com
    Port 443
    User git
    IdentityFile ~/.ssh/id_ed25519

GitHub提供了ssh.github.com:443作为备用SSH入口。

小结

在中国：首选SSH，HTTPS作为备用。

下一节，我们来学习国内镜像加速。

13.4 国内镜像加速：ghproxy 等工具的使用

除了代理，还有一种方案是使用国内镜像服务。这些服务把GitHub的内容缓存到国内服务器，你访问的是国内服务器，速度自然就快了。就像你在国内看YouTube视频，通过缓存服务器播放，而不是直接连接美国。

什么是镜像加速？

镜像服务会在国内服务器上缓存GitHub的内容。当你clone或pull时，实际上是从国内服务器下载，速度飞快。

┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│   你的电脑   │ ──────▶ │  国内镜像    │ ──────▶ │   GitHub    │
│  （北京）   │  飞快！  │ （上海/深圳）│  后台同步 │  （旧金山）   │
│             │ ◀────── │             │ ◀────── │             │
└─────────────┘         └─────────────┘         └─────────────┘
     快速访问                缓存内容               原始仓库

ghproxy 镜像代理

ghproxy 是最流行的GitHub镜像代理服务之一，开源且稳定。

使用方法：

把GitHub地址中的 github.com 替换为 mirror.ghproxy.com/github.com：

1
2
3
4
5

# 原地址
https://github.com/username/repo.git

# 使用ghproxy
https://mirror.ghproxy.com/github.com/username/repo.git

clone示例：

1
2
3
4
5
6
7

# 直接clone
$ git clone https://mirror.ghproxy.com/github.com/facebook/react.git

# 速度对比（实际测试）
# 直接clone：10-50 KB/s
# 使用ghproxy：1-5 MB/s
# 提升100倍！

设置Git别名（更方便使用）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 添加Git URL替换规则
# 这样你可以继续使用原地址，Git会自动转换
$ git config --global url."https://mirror.ghproxy.com/github.com/".insteadOf "https://github.com/"

# 现在可以直接用原地址，实际走的是ghproxy
$ git clone https://github.com/facebook/react.git
# 实际使用的是：https://mirror.ghproxy.com/github.com/facebook/react.git

# 查看配置
$ git config --global --get-regexp url

取消别名：

1

$ git config --global --unset url."https://mirror.ghproxy.com/github.com/".insteadOf

其他镜像服务

使用示例：

1
2
3
4
5

# fastgit
$ git clone https://hub.fastgit.xyz/facebook/react.git

# gitclone（需要加github.com前缀）
$ git clone https://gitclone.com/github.com/facebook/react.git

镜像的局限性

镜像服务虽然快，但也有局限：

1. 只读

镜像服务通常只支持clone和pull，不支持push。你只能下载，不能上传。

2. 延迟

镜像是后台同步的，内容可能不是最新的。刚push的代码可能要等几分钟才能在镜像上看到。

3. 不稳定

免费镜像服务可能随时关闭或限速。不要过度依赖。

4. 安全性

使用第三方镜像服务，你的代码会经过他们的服务器。对于私有仓库或敏感代码，建议使用代理而不是镜像。

镜像使用建议

小结

镜像加速适合只读场景：

• ghproxy：最流行，推荐使用
• 速度快：提升10-100倍
• 配置简单：一行命令搞定
• 注意局限：只读，可能有延迟

对于需要push的场景，还是建议使用代理或SSH。

下一节，我们来学习Gitee导入——国内访问的终极方案。

13.5 Gitee 导入：国内访问的终极方案

如果你经常需要访问某个GitHub项目，或者需要完整的功能（clone+push），可以把它导入到Gitee（码云），然后使用Gitee的地址访问。这是国内访问的终极方案，速度飞快且功能完整。

为什么用Gitee？

Gitee（码云）是国内最大的代码托管平台，由开源中国运营。

优势：

• 国内服务器：访问速度飞快，clone速度可达10MB/s+
• 自动同步：可以设置自动从GitHub同步，保持最新
• 完整功能：支持clone、push、issue、PR等所有功能
• 稳定可靠：国内大厂运营，不会突然关闭
• 中文支持：全中文界面，文档也是中文

劣势：

• 国际影响力小：国外开发者基本不用
• 审核机制：公有仓库需要审核，可能有几分钟到几小时的延迟
• 社区生态：开源项目数量不如GitHub

导入GitHub项目到Gitee

步骤1：登录Gitee

访问 https://gitee.com 并登录账号。

步骤2：创建仓库

点击右上角 “+” 按钮 → “从GitHub/GitLab导入仓库”。

步骤3：填写GitHub地址

输入GitHub仓库地址，例如：

https://github.com/facebook/react

步骤4：配置导入选项

• 仓库名称：可以自定义，建议保持原名
• 仓库介绍：可选，可以留空
• 是否开源：
  • 开源：所有人可见（需要审核）
  • 私有：仅自己可见（立即创建）
• 开启自动同步：⭐ 强烈推荐勾选
  • Gitee会定期（通常每天）从GitHub同步最新代码
  • 保持两边代码一致

步骤5：等待导入完成

根据仓库大小，导入时间从几秒到几分钟不等。导入完成后，你就可以使用Gitee地址访问了：

https://gitee.com/你的用户名/react

使用Gitee地址

克隆仓库：

1
2

# 从Gitee克隆（飞快！）
$ git clone https://gitee.com/你的用户名/react.git

添加GitHub作为upstream（双保险）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 克隆后进入仓库
$ cd react

# 查看当前远程
$ git remote -v
origin  https://gitee.com/你的用户名/react.git

# 添加GitHub作为upstream
$ git remote add upstream https://github.com/facebook/react.git

# 验证
$ git remote -v
origin   https://gitee.com/你的用户名/react.git
upstream https://github.com/facebook/react.git

日常使用：

1
2
3
4
5
6
7
8

# 平时从Gitee拉取（快）
$ git pull origin main

# 需要同步GitHub最新代码时
$ git pull upstream main

# 推送到Gitee
$ git push origin main

自动同步设置

Gitee支持自动同步，保持和GitHub一致：

设置方法：

1. 进入Gitee仓库页面
2. 点击 “设置” → “仓库设置” → “同步设置”
3. 开启 “自动同步”
4. 设置同步频率：
   • 每天一次（推荐）
   • 每周一次
   • 手动同步

手动同步：

如果不想等自动同步，可以手动触发：

1. 进入Gitee仓库
2. 点击 “同步” 按钮
3. 等待同步完成

贡献代码回GitHub

如果你在Gitee上修改了代码，想贡献回GitHub：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 1. 从Gitee推送修改
$ git push origin main

# 2. 在GitHub上Fork原项目（如果你还没有）

# 3. 添加你的GitHub Fork作为remote
$ git remote add myfork https://github.com/你的GitHub用户名/react.git

# 4. 推送到你的GitHub Fork
$ git checkout -b my-feature
$ git push myfork my-feature

# 5. 在GitHub上创建PR

注意事项

1. 同步延迟

自动同步有延迟，不是实时的。如果你需要GitHub上最新的代码：

• 手动触发同步
• 或者直接使用GitHub地址pull

2. 私有仓库

私有仓库导入后仍然是私有的，但要注意：

• 代码会经过Gitee服务器
• 敏感项目谨慎使用

3. 大仓库

超大仓库（如Linux内核）导入可能失败或很慢。可以：

• 使用浅克隆
• 只导入需要的分支

4. 审核时间

公有仓库需要审核，通常几分钟到几小时。如果急用：

• 先创建为私有仓库
• 导入完成后再改为公有

小结

Gitee导入是终极方案：

• 速度最快：国内服务器，10MB/s+
• 功能完整：clone、push、issue、PR都支持
• 自动同步：保持和GitHub同步
• 适合场景：经常访问的项目、需要push的场景

对于GitHub访问困难的用户，Gitee是最佳选择！

下一节，我们来学习浅克隆——大仓库的救命稻草。

13.6 浅克隆 --depth=1：大仓库的救命稻草

如果你只需要仓库的最新代码，不需要完整的历史记录，可以使用浅克隆（Shallow Clone）。这能大大加快clone速度，节省磁盘空间。就像你去图书馆借书，只需要最新版，不需要所有旧版本。

什么是浅克隆？

浅克隆只下载最近的几个提交，而不是完整的历史记录。默认情况下，Git会下载仓库的所有历史，包括几年前的每一个提交。对于大仓库，这可能需要下载几个GB的数据。浅克隆只下载你需要的部分。

完整克隆：A---B---C---D---E---F (100MB，包含所有历史)
                    ↑
                 所有提交

浅克隆：              E---F (10MB，只包含最近2个提交)
                      ↑
                   只下载这些

使用方法

基本用法：

1
2
3
4
5
6
7
8

# 只克隆最近1个提交（最常用）
$ git clone --depth=1 https://github.com/large-repo/large-repo.git

# 克隆最近10个提交
$ git clone --depth=10 https://github.com/large-repo/large-repo.git

# 克隆最近50个提交
$ git clone --depth=50 https://github.com/large-repo/large-repo.git

克隆特定分支的最近提交：

1
2
3
4
5

# 只克隆main分支的最近1个提交
$ git clone --depth=1 --branch main https://github.com/large-repo/large-repo.git

# 克隆develop分支的最近10个提交
$ git clone --depth=10 --branch develop https://github.com/large-repo/large-repo.git

浅克隆的优势

浅克隆的局限

浅克隆虽然快，但也有一些限制：

1. 看不到完整历史

1
2
3
4

# 浅克隆后，git log只能看到最近的提交
$ git log --oneline
a1b2c3d Latest commit
# 就这些，前面的历史看不到

2. 某些操作受限

• 不能rebase（因为没有完整历史）
• 不能查看旧版本
• 某些Git命令会报错

3. 不能推送

浅克隆通常用于只读场景，不能直接push回远程。

1
2

$ git push origin main
fatal: shallow update not allowed

转换为完整仓库

如果你后来需要完整历史，可以"加深"克隆：

1
2
3
4
5
6
7
8
9

# 获取所有历史（取消浅克隆限制）
$ git fetch --unshallow

# 或者获取更多提交（比如最近100个）
$ git fetch --depth=100

# 查看是否成功
$ git log --oneline
# 现在可以看到更多历史了

实际案例：Linux内核

Linux内核仓库是超级大的仓库，完整克隆需要几个GB：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 完整克隆（几个GB，可能需要几小时）
$ time git clone https://github.com/torvalds/linux.git
# 输出：real 120m30s（2小时！）

# 删除
$ rm -rf linux

# 浅克隆（几十MB，只需要几分钟）
$ time git clone --depth=1 https://github.com/torvalds/linux.git
# 输出：real 2m15s（2分钟！）
# 速度快了50倍！

使用场景

最佳实践

1. CI/CD环境使用浅克隆

1
2
3
4
5

# .github/workflows/ci.yml
steps:
  - uses: actions/checkout@v4
    with:
      fetch-depth: 1  # 只克隆最近1个提交

2. 开发时先浅克隆，需要时再加深

1
2
3
4
5

# 先浅克隆快速开始
$ git clone --depth=1 https://github.com/large-repo/large-repo.git

# 工作一段时间后，如果需要历史
$ git fetch --unshallow

3. 结合单分支克隆

1
2

# 只克隆main分支的最近1个提交（最快）
$ git clone --single-branch --branch main --depth=1 https://github.com/large-repo/large-repo.git

小结

浅克隆是大仓库的救命稻草：

• --depth=1：只克隆最近1个提交
• 速度快：提升10-100倍
• 省空间：节省90%磁盘空间
• 适合场景：CI/CD、临时查看、快速开始

记住：--depth=1 是处理大仓库的利器！

下一节，我们来学习单分支克隆。

13.7 只克隆单个分支：--single-branch 提速

如果你只需要某个特定分支，可以使用 --single-branch 选项，只克隆该分支，忽略其他分支。这可以进一步减少下载量，加快clone速度。

什么是单分支克隆？

默认情况下，git clone 会下载所有分支的引用（虽然只检出默认分支）。--single-branch 只下载指定分支，其他分支完全不下载。

完整克隆：
- main分支（检出）
- develop分支（引用）
- feature-xxx分支（引用）
- 所有标签
- 所有历史

单分支克隆：
- main分支（只下载这个）

使用方法

基本用法：

1
2
3
4
5
6
7
8

# 只克隆main分支
$ git clone --single-branch --branch main https://github.com/user/repo.git

# 只克隆develop分支
$ git clone --single-branch --branch develop https://github.com/user/repo.git

# 只克隆某个feature分支
$ git clone --single-branch --branch feature-new-ui https://github.com/user/repo.git

和浅克隆结合（最快）：

1
2
3
4

# 只克隆main分支的最近1个提交（最快配置）
$ git clone --single-branch --branch main --depth=1 https://github.com/user/repo.git

# 这个组合可以最大程度减少下载量

适用场景

查看克隆后的分支

1
2
3
4
5
6

# 单分支克隆后，只能看到指定分支
$ git branch -a
* main
  remotes/origin/main

# 看不到其他分支

获取其他分支（如果需要）

如果后来需要其他分支：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 获取远程分支列表
$ git fetch origin

# 现在可以看到其他分支了
$ git branch -r
  origin/main
  origin/develop
  origin/feature-xxx

# 检出其他分支
$ git checkout -b develop origin/develop

小结

--single-branch 可以进一步减少下载量：

• 只下载指定分支
• 和 --depth=1 配合使用效果最佳
• 适合只需要特定分支的场景

下一节，我们来学习子模块加速。

13.8 子模块加速：当项目依赖其他仓库时

有些项目使用Git子模块（Submodule）来管理依赖。子模块是嵌套在其他Git仓库中的Git仓库。克隆这样的项目时，默认会递归下载所有子模块，这可能很慢。这一节我们学习如何加速子模块的下载。

什么是子模块？

子模块允许你将一个Git仓库作为另一个Git仓库的子目录。常用于：

• 管理项目依赖
• 共享公共库
• 组织大型项目

主项目/
├── src/              # 主项目代码
├── docs/             # 文档
└── vendor/           # 第三方库（子模块）
    ├── lib-a/        # 子模块：库A
    └── lib-b/        # 子模块：库B

子模块的问题

克隆包含子模块的项目时：

1
2
3

# 默认会递归克隆所有子模块
$ git clone --recursive https://github.com/user/repo-with-submodules.git
# 这可能非常慢，因为子模块可能很多、很大

子模块加速技巧

1. 不克隆子模块

如果你不需要子模块，可以不克隆：

1
2
3
4
5
6

# 不克隆子模块
$ git clone --recurse-submodules=no https://github.com/user/repo-with-submodules.git

# 或者简写
$ git clone https://github.com/user/repo-with-submodules.git
# 默认就是不递归克隆

2. 浅克隆子模块

1
2
3
4

# 递归克隆，但子模块也浅克隆
$ git clone --recurse-submodules --shallow-submodules --depth=1 https://github.com/user/repo-with-submodules.git

# --shallow-submodules 表示子模块也使用浅克隆

3. 手动初始化子模块

先克隆主项目，然后只初始化需要的子模块：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# 先克隆主项目（不包含子模块）
$ git clone https://github.com/user/repo-with-submodules.git

# 进入项目
$ cd repo-with-submodules

# 查看有哪些子模块
$ cat .gitmodules
[submodule "vendor/lib-a"]
    path = vendor/lib-a
    url = https://github.com/vendor/lib-a.git
[submodule "vendor/lib-b"]
    path = vendor/lib-b
    url = https://github.com/vendor/lib-b.git

# 只初始化需要的子模块
$ git submodule update --init --depth=1 vendor/lib-a

# 不需要lib-b，就不初始化

4. 使用代理加速子模块

配置Git使用代理，子模块也会走代理：

1
2
3
4

$ git config --global http.proxy http://127.0.0.1:1080

# 然后克隆
$ git clone --recursive https://github.com/user/repo-with-submodules.git

5. 使用国内镜像加速子模块

如果子模块也在GitHub上，可以使用镜像：

1
2
3
4
5
6
7
8
9

# 先克隆主项目
$ git clone https://github.com/user/repo-with-submodules.git
$ cd repo-with-submodules

# 修改子模块URL为镜像地址
$ git config submodule.vendor/lib-a.url https://mirror.ghproxy.com/github.com/vendor/lib-a.git

# 初始化子模块
$ git submodule update --init vendor/lib-a

子模块常用命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 初始化子模块
$ git submodule update --init

# 初始化并更新所有子模块
$ git submodule update --init --recursive

# 更新子模块到最新
$ git submodule update --remote

# 添加子模块
$ git submodule add https://github.com/vendor/lib.git vendor/lib

# 删除子模块（复杂，需要多步）
$ git submodule deinit -f vendor/lib
$ rm -rf .git/modules/vendor/lib
$ git rm -f vendor/lib

小结

子模块加速技巧：

• 不克隆不需要的子模块
• 浅克隆子模块
• 手动初始化需要的子模块
• 使用代理或镜像

下一节，我们来学习网络问题排查。

13.9 网络问题排查：从 DNS 到防火墙

遇到GitHub连接问题？不要慌，这一节我们来系统性地排查和解决各种网络问题。

排查步骤清单

第一步：检查网络连接

1
2
3
4
5
6
7
8

# ping测试：看看能否连通
$ ping github.com

# 正常应该能看到回复
Pinging github.com [140.82.114.4] with 32 bytes of data:
Reply from 140.82.114.4: bytes=32 time=200ms TTL=50

# 如果ping不通，说明网络有问题

第二步：检查DNS解析

1
2
3
4
5
6
7

# 查看GitHub解析到的IP
$ nslookup github.com
# 或
$ dig github.com

# 正常应该返回GitHub的IP
# 如果返回错误的IP，说明DNS被污染了

第三步：修改Hosts文件

如果DNS解析错误，可以手动指定正确的IP：

1. 查询GitHub的正确IP（通过 https://www.ipaddress.com ）

2. 修改hosts文件：

   • Windows: C:\Windows\System32\drivers\etc\hosts
   • Linux/Mac: /etc/hosts

3. 添加以下内容（IP需要自行查询最新的）：

# GitHub相关域名
140.82.114.4 github.com
140.82.114.4 api.github.com
140.82.113.4 gist.github.com
185.199.108.133 raw.githubusercontent.com
185.199.109.133 raw.githubusercontent.com
185.199.110.133 raw.githubusercontent.com
185.199.111.133 raw.githubusercontent.com

4. 刷新DNS缓存：
   • Windows: ipconfig /flushdns
   • Linux: sudo systemctl restart nscd 或 sudo systemd-resolve --flush-caches
   • Mac: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

第四步：检查代理配置

1
2
3
4
5
6
7

# 查看Git代理配置
$ git config --global --get http.proxy
$ git config --global --get https.proxy

# 测试代理是否工作
$ curl -x http://127.0.0.1:1080 https://github.com
# 如果能返回HTML，说明代理正常

第五步：检查防火墙

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 检查22端口（SSH）
$ telnet github.com 22
# 或
$ nc -vz github.com 22

# 检查443端口（HTTPS）
$ telnet github.com 443
# 或
$ nc -vz github.com 443

# 如果端口不通，可能是防火墙阻止

常见问题及解决方案

问题1：SSL证书错误

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 错误信息：
# SSL certificate problem: unable to get local issuer certificate

# 临时解决方案（不推荐长期使用）
$ git config --global http.sslVerify false

# 更好的解决方案：更新CA证书
# Windows: 更新系统
# Linux: sudo apt-get update && sudo apt-get install ca-certificates
# Mac: 更新系统

问题2：连接超时

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 错误信息：
# Failed to connect to github.com port 443: Connection timed out

# 解决方案1：增加超时时间
$ git config --global http.lowSpeedLimit 0
$ git config --global http.lowSpeedTime 999999

# 解决方案2：使用代理
$ git config --global http.proxy http://127.0.0.1:1080

# 解决方案3：修改hosts（见上文）

问题3：DNS污染

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 症状：能ping通，但浏览器打不开
# 原因：DNS解析到错误的IP

# 解决方案：使用公共DNS
# 阿里DNS：223.5.5.5, 223.6.6.6
# 腾讯DNS：119.29.29.29
# 114DNS：114.114.114.114
# Google DNS：8.8.8.8（可能不稳定）

# Windows修改DNS：
# 控制面板 → 网络和共享中心 → 更改适配器设置 → 右键属性 → IPv4 → 使用下面的DNS

# Linux修改DNS：
# 编辑 /etc/resolv.conf
nameserver 223.5.5.5
nameserver 223.6.6.6

问题4：代理连接失败

1
2
3
4

# 症状：配置了代理但连不上
# 检查代理软件是否运行
# 检查代理地址和端口是否正确
# 尝试更换代理协议（HTTP vs SOCKS5）

网络问题排查流程图

遇到问题
   ↓
ping github.com
   ↓
不通 → 检查网络连接 → 检查DNS → 修改hosts
   ↓
通了但慢
   ↓
检查代理配置 → 配置代理 → 测试速度
   ↓
还是慢
   ↓
使用镜像/Gitee → 浅克隆 → 完成！

小结

网络问题排查清单：

• ping测试网络连通性
• 检查DNS解析
• 修改hosts（必要时）
• 检查代理配置
• 检查防火墙
• 使用公共DNS

记住：遇到问题不要慌，按步骤排查，总能解决！

下一节，我们来了解备用方案。

13.10 备用方案：码云、Coding、阿里云效、AtomGit 等

如果GitHub实在访问不了，或者速度太慢影响工作，国内还有很多优秀的代码托管平台可以作为备用。这些平台服务器在国内，访问速度飞快，功能也很完善。

国内平台对比

Gitee（码云）—— 国内首选

优势：

• 国内访问速度最快，clone速度可达10MB/s+
• 支持从GitHub自动同步
• 开源项目多，社区活跃
• 免费私有仓库

劣势：

• 国际影响力小
• 公有仓库需要审核

适用场景：

• GitHub的国内镜像
• 个人开源项目
• 需要快速访问的场景

Coding—— 腾讯出品

优势：

• 腾讯生态，稳定性好
• DevOps功能强大（CI/CD、项目管理）
• 私有仓库免费
• 支持企业微信集成

劣势：

• 社区不如Gitee活跃
• 部分高级功能收费

适用场景：

• 企业团队开发
• 需要DevOps工具链
• 腾讯生态用户

阿里云效—— 阿里生态

优势：

• 阿里生态，和阿里云集成好
• 企业级功能完善
• 支持大规模团队协作

劣势：

• 个人开发者功能有限
• 部分功能收费

适用场景：

• 阿里云用户
• 企业级项目
• 大规模团队协作

AtomGit—— 开源基金会

优势：

• 开放原子开源基金会运营
• 支持开源项目
• 公益性质

劣势：

• 较新，生态还在建设中

适用场景：

• 开源基金会项目
• 开源贡献

迁移建议

如果GitHub实在用不了：

1. 主力开发迁移到Gitee

   • 把常用项目导入Gitee
   • 设置自动同步保持更新

2. 保留GitHub作为备份

   • 定期从Gitee同步到GitHub
   • 保持GitHub上的绿格子

3. 团队协作选择

   • 小团队：Gitee或Coding
   • 企业团队：Coding或阿里云效
   • 开源项目：AtomGit

多平台同步策略

GitHub（原始仓库）
    ↓ 自动同步
Gitee（国内镜像） ← 主力开发
    ↓ 定期推送
Coding（备份）

小结

国内平台选择建议：

• 个人开源：Gitee（速度快，生态好）
• 企业团队：Coding（DevOps完善）或阿里云效（阿里生态）
• 开源基金会：AtomGit
• GitHub备份：Gitee自动同步

记住：不要把鸡蛋放在一个篮子里，多平台备份更安心！

本章小结

恭喜！你已经掌握了GitHub网络优化的全套技能，从"龟速"变"神速"！

优化方案总结

推荐配置（按优先级）

日常开发配置：

1. 配置SSH密钥（一劳永逸）
2. 设置代理（仅对GitHub生效）
3. 常用项目导入Gitee并开启自动同步

CI/CD环境配置：

1. 使用 --depth=1 浅克隆
2. 使用 --single-branch 单分支克隆
3. 使用国内镜像

应急方案：

1. 使用Gitee访问
2. 使用镜像服务
3. 修改hosts

重要提醒

• 代理是最有效的方案，强烈推荐配置
• SSH比HTTPS更稳定，在中国网络环境下首选
• 浅克隆能节省大量时间，大仓库必备
• 国内平台是可靠的后备，不要忽视

希望这些技巧能让你的GitHub体验从"想砸键盘"变成"丝般顺滑"！

本章完 | Chapter 13 Complete