Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

如何克隆一个大 Git 项目 #131

Open
xizhibei opened this issue Feb 10, 2020 · 2 comments
Open

如何克隆一个大 Git 项目 #131

xizhibei opened this issue Feb 10, 2020 · 2 comments

Comments

@xizhibei
Copy link
Owner

xizhibei commented Feb 10, 2020

用 Git 克隆新项目,可以说是每个工程师必备的基础技能,然而,当你遇到克隆过程中的各种各样问题的时候,可知道如何处理?

遇到问题

某天在工作中,小 A 像往常一样要克隆一个新项目到本地,于是你熟练地敲下

git clone git://github.com:example/awesome-project

然后很悲催的,小 A 发现它告诉你这个项目有几个 G:

Cloning into 'awesome-project'...
remote: Enumerating objects: 17400, done.
remote: Counting objects: 100% (17400/17400), done.
remote: Compressing objects: 100% (11300/11300), done.
Receiving objects:  1% (2351/127770), 40.57 MiB | 8.00 KiB/s

Depth 命令参数

好不容易等了几个小时,进度只有 20%。于是,小 A 请教身边的大牛,他告诉小 A 如果不是很在意历史,其实可以用 depth 参数,这样会快很多。

git clone --depth=1 git://github.com:example/awesome-project

但是小 A 是想要全部克隆下来,然后大牛告诉小 A ,用 depth 参数克隆的项目,是可以恢复全部历史的。

于是小 A 开始尝试,发现需要下载的内容少了好多:

Cloning into 'awesome-project'...
remote: Enumerating objects: 200, done.
remote: Counting objects: 100% (200/200), done.
remote: Compressing objects: 100% (200/200), done.
Receiving objects:  1% (1/188), 1.01 MiB | 80.00 KiB/s

之后,大牛给小 A 发来了 clone 之后的操作步骤:

git fetch --unshallow
git pull --all

但是这速度怎么回事,好慢。

代理

大牛瞥了一眼小 A 的屏幕,转头告诉小 A ,用代理会快好多。

然后小 A 又去折腾代理去了,回来之后测试:

git config --global http.proxy=http://172.0.0.1:7777
git clone --depth=1 git://github.com:example/awesome-project

但是小 A 发现,为何代理似乎不起作用:

Cloning into 'awesome-project'...
remote: Enumerating objects: 200, done.
remote: Counting objects: 100% (200/200), done.
remote: Compressing objects: 100% (200/200), done.
Receiving objects:  1% (1/188), 0.56 MiB | 40.00 KiB/s

大牛这时候提醒小 A,在他克隆的时候,用的是 git 协议的项目地址,实际上是 ssh 协议,因此不能用 http proxy 来达到这个目的。

大牛手把手教小 A 在 ~/.ssh/config 中,加入如下的配置(这时候注意,用的是本地的 socks 代理,而不是上面的 http 代理):

Host gitlab.com
    ProxyCommand=nc -X 5 -x 127.0.0.1:7778 %h %p
    HostName gitlab.com
    User git

重试尝试,发现速度快了很多:

Cloning into 'awesome-project'...
remote: Enumerating objects: 200, done.
remote: Counting objects: 100% (200/200), done.
remote: Compressing objects: 100% (200/200), done.
Receiving objects:  1% (1/188), 20.13 MiB | 800.00 KiB/s

小 A 愉快地等着,看着进度一点一点变多。

然而,命运总是喜欢跟小 A 开玩笑,等到了 99% 的时候,

Cloning into 'awesome-project'...
remote: Enumerating objects: 200, done.
remote: Counting objects: 100% (200/200), done.
remote: Compressing objects: 100% (200/200), done.
fatal: The remote end hung up unexpectedly1.95 GiB | 772.00 KiB/s    
fatal: early EOF
fatal: index-pack failed

于是,小 A 想打人。

core.compress 配置

小 A 又焦虑了,这是咋回事。

看着一盘大牛忙碌的样子,打算自己去解决,搜索一阵后,在 StackOverflow 上发现了答案:其实这种问题,很有可能是 Git 服务器的内存不够了,导致压缩传输数据失败,服务器直接挂了。

于是,小 A 看了看 Git config 文档

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.

就尝试设置这个参数:

git config --global core.compression=0

也就是取消压缩,这样的话,项目可以不经过压缩就直接传输。

总结与反思

终于克隆成功了。

然而打开编辑器,看了看项目中的一些文件,小 A 头都大了:这项目的维护者水平堪忧,为什么放上一堆明明可以通过编译生成的可执行文件跟压缩文件?大牛可是教我们不能把这些东西放在项目里面的。

原因似乎也找到了:太多不必要的大文件也放在了项目里,导致项目庞大臃肿,克隆的时候遇到那么多问题,都是这些文件导致的。

那,如果你是这类项目的维护者,该如何去改善?且听下回分解。

@WyattJia
Copy link

亲亲,一个仓库超过几个 G 已经是不规范用法了,这边建议使用 P4 呢。

@xizhibei
Copy link
Owner Author

亲亲,一个仓库超过几个 G 已经是不规范用法了,这边建议使用 P4 呢。

P4 看起来是大企业才用的,但也是一个解决方案了

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants