1. 为什么你的 git clone 总是慢如蜗牛？
不知道你有没有过这样的经历：好不容易在 GitHub 上找到一个心仪的开源项目，满心欢喜地敲下 git clone 命令，结果进度条像蜗牛一样，半天才动一点点。更让人崩溃的是，如果这个项目还包含了子模块（submodule），用上 git clone --recursive 之后，那等待的时间简直可以用来泡杯茶，甚至睡个午觉。我之前接手一个大型 C++ 项目，里面依赖了十几个子模块，第一次完整克隆花了将近两个小时，期间网络还断了几次，那种感觉真是欲哭无泪。
网上常见的解决方案，比如修改系统的 hosts 文件，或者把 Git 的远程仓库地址换成国内的镜像源，相信很多人都试过。这些方法不能说完全没用，在某些网络环境下确实能带来一些改善。但问题在于，它们往往'治标不治本'。改 hosts 需要对网络有比较深的理解，操作有风险，而且一旦 GitHub 的 IP 变了，又得重新找、重新改，非常麻烦。而直接替换克隆地址，比如把 github.com 换成 github.com.cnpmjs.org，对于单个仓库克隆是有效的，速度提升立竿见影。可一旦遇到带子模块的项目，这个方法就瞬间失效了。因为你只能加速主仓库的克隆，那些子模块的原始地址（通常还是指向 github.com）依然会以龟速进行下载，瓶颈并没有真正解决。
所以，我们需要的是一个更优雅、更彻底的方案。它应该满足几个条件：第一，不需要我们每次克隆都手动修改一长串的 URL；第二，对于项目中的子模块也能自动生效；第三，配置一次，终身受益，对所有 Git 操作都透明。今天要分享的，就是这样一个我摸索了很久，并且在多个项目和团队中验证过的'终极方案'。它完全不需要你动系统级的镜像源或者 hosts 文件，仅仅通过修改 Git 自身的两个配置文件，就能实现全局性的克隆加速，包括递归克隆。下面，我就带你一步步把它搭建起来。
2. 核心原理：Git 的 URL 重写魔法
在深入具体操作之前，我们花点时间了解一下这个方案的核心——Git 的 url.<base>.insteadOf 配置项。理解了这个，你就能举一反三，而不仅仅是照搬命令。
你可以把这个配置想象成 Git 内部的一个'地址翻译器'。它的工作非常简单：当你通过 Git 命令（如 clone, fetch, pull, push）访问某个远程仓库地址时，Git 会先检查这个地址是否匹配你预先设定的'原始地址'（insteadOf 左边的部分）。如果匹配，它就会在真正发起网络请求前，自动将地址'翻译'成你设定的'目标地址'（insteadOf 右边的部分）。这个过程对你是完全透明的，你敲的命令不需要做任何改变。
举个例子，我们最常遇到的慢，是慢在访问 https://github.com/。国内有很多公益的 GitHub 镜像站，比如 github.com.cnpmjs.org 和 hub.fastgit.org（请注意，后者可能已变更或停止服务，使用时请查询最新可用镜像），它们定时从 GitHub 同步代码，我们在国内访问这些镜像站速度会快很多。那么，我们就可以配置一条规则：将所有指向 https://github.com/ 的请求，自动重定向到 https://github.com.cnpmjs.org/。
这样一来，无论你是直接克隆 https://github.com/username/repo.git，还是你的项目中的 .gitmodules 文件里子模块的地址是 https://github.com/other/lib.git，Git 都会在背后悄无声息地把地址替换掉。你看到的、你输入的，都是原始的 GitHub 地址，但实际的数据传输却走了高速的镜像通道。这就是为什么这个方法能'一劳永逸'地解决包括递归克隆在内的所有速度问题。
它比直接修改 .gitmodules 文件更先进。因为直接修改文件内容只对当前项目生效，如果你换一台电脑或者重新克隆，又得改一遍。而这个配置是写在你的 Git 全局配置（~/.gitconfig）里的，它跟着你的 Git 用户走，在任何仓库、任何目录下都会自动生效。它也比系统级的方案更安全、更聚焦，不会影响你电脑上的其他网络应用。
3. 一步到位的全局加速配置
好了，原理清楚了，我们现在开始动手。整个配置过程非常简单，只需要一条命令。
打开你的终端（Windows 用户请打开 Git Bash 或 CMD/PowerShell），输入以下命令：
git config --global url."https://github.com.cnpmjs.org/".insteadOf "https://github.com/"
