go依赖包下载加速方法及github加速
对于https://github.com/kubernetes/kubernetes整个仓库大小为近900M，下载起来那个伤心：
- 方法一：使用码云
这是码云上的的说明：
此仓库是为了提升国内下载速度的镜像仓库，每日同步一次先从码云下载到本地，然后修改./git/config为github的仓库地址，再次git pull拉取最新的commit，这样
就和github保持一致 - 方法二：github加速 https://www.ipaddress.com
- 方法三：github代码下载分三种方法：
- ssh代理设置：环境变量
export http_proxy=http://127.0.0.1:8123 export https_proxy=https://127.0.0.1:8123- https 代理设置：git自带设置
git config --global http.proxy http://127.0.0.1:8123 git config --global https.proxy https://127.0.0.1:8123git config --global --unset https.proxy git config --global --unset http.proxy- 试试http下载：
无效关闭SSL CERT verification，但是http下载前会跳转到https：
git config --global http.sslverify false
- 断点续传：伪断点续传
git clone原理是先创建一个临时文件夹，中间打断，会完全删除这个文件，白忙活了。
一种方法：git init + git fetch + git checkout -b
git clone --depth=1 --single-branch --branch branch_name repository_url
含义是：只拉取分支branch_name的最新的一次提交。如果需要再往前拉取提交，进入分支里执行
git fetch --depth=2表示再往前拉取2次commit(github)或者是总共拉取2次最新的提交(gerrit)。此时.git/config里remote的fetch配置是这样的，指定了分支名字。所有你此后的git fetch/pull/push
都是只针对这一个分支。
bash [remote "origin"] url = ssh://[email protected]:29418/ganghui.zeng/gerrit_test fetch = +refs/heads/branch_name:refs/remotes/origin/branch_name
而一般的git clone的配置是这样的，*号表示可以所有分支[remote "origin"] url = ssh://[email protected]:29418/ganghui.zeng/gerrit_test fetch = +refs/heads/*:refs/remotes/origin/*至于网传的mkdir test;cd test;git init;get fetch origin_url branch_name方法，并不见效，
只是生成了很多临时文件，每次重新fetch都重新生成一个新的文件：? test1 git:(master) ll .git/objects/pack total 1625256 -r--r--r-- 1 xxx staff 59170815 3 27 11:49 tmp_pack_2m74Z9 -r--r--r-- 1 xxx staff 14618623 3 27 13:36 tmp_pack_J10P9a -r--r--r-- 1 xxx staff 2277375 3 27 13:34 tmp_pack_ibufua -r--r--r-- 1 xxx staff 115097599 3 27 11:51 tmp_pack_jAwUL9 -r--r--r-- 1 xxx staff 89423871 3 27 11:47 tmp_pack_l3gmma -r--r--r-- 1 xxx staff 505364479 3 27 12:00 tmp_pack_odHgOb -r--r--r-- 1 xxx staff 30613503 3 27 15:06 tmp_pack_x52D38 -r--r--r-- 1 xxx staff 12353535 3 27 14:01 tmp_pack_ypFPT9 - git仓库臃肿问题解决
记一次删除Git记录中的大文件的过程
经过一阵操作，感受下偶尔上M的下载速度吧
原文地址：https://www.cnblogs.com/shengulong/p/10651248.html