通过慢速网络连接在 git 中工作的最快方法是啥？

Posted 2023-02-22

【中文标题】通过慢速网络连接在 git 中工作的最快方法是啥？

【英文标题】：What's the fastest way to work in git over a slow network connection?通过慢速网络连接在 git 中工作的最快方法是什么？

【发布时间】：2011-12-20 13:59:25

【问题描述】：

情况是这样的：在工作中，我们有很多分支，但我们没有让 repo 保持应有的整洁，偶尔会添加/删除大文件或诸如此类的东西，并且很少删除死分支。

所以今天是下雪天，我必须在家工作。我的 *** 连接速度很慢，我所需要的只是以最快的方式到达我关心的分支并开始工作，并且能够将提交推回。

在 SVN 中，我只需更新所需的路径/文件，就可以立即工作。像大多数 git 新手一样，我只有少数几个受信任的命令，而且我的备用 git clone 或 git pull 会太慢。

所以这似乎是一个两部分的问题：

如何克隆存储库以尽快开始工作，以及 如何从这个 repo 中拉取/推送（编辑、提交、拉取、推送）

可行的解决方案（根据@g19fanatic 的以下建议）：

> git clone -b <branchname> <repo_url> --depth=1
remote: Counting objects: 16679, done.
remote: Compressing objects: 100% (11926/11926), done.
remote: Total 16679 (delta 6936), reused 10919 (delta 3337)
Receiving objects: 100% (16679/16679), 628.12 MiB | 430 KiB/s, done.
Resolving deltas: 100% (6936/6936), done.
> git pull
Already up-to-date.

（在其他机器上进行小改动，提交/推送）

> git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 0 (delta 0)

太好了，这给我留下了一个工作回购。

唯一的问题是它最初传输的数据量是下面failed attempts 的两倍，但它确实使存储库处于可用状态。我会认为这已得到解答，但我认为初始传输大小可能会有所改进。

【问题讨论】：

今天仍然是一个相关问题！但是，确实，仍然不是一个好的答案。我的仓库很整洁，我的连接更糟糕，我只需要更好的异步操作！此外，这可以通过遵循站点标准来大大改善......只需将 cmets 和答案留在它们所属的地方。

【参考方案1】：

在这里做一个小测试，我能够做到以下......

我们在网络上有一个共享的 --bare repo

我的远程设置为git remote add origin <pathToSharedRepo> 我做了一个git pull origin <branch> --depth=1（不是git fetch，而是git pull）

这只会成功拉取此分支的“HEAD + depth”提交。我可以对此等进行提交，然后将其推送（git push 应该可以正常工作）它没有问题地退出。

要提取新提交并仅从共享存储库中提取新提交，我必须显式键入 git pull origin <branch>。由于这是我最初（明确）进行拉动的方式，所以这次我必须这样做......

这不应该比你最初设置的深度拉下更多的历史（它不在乎）

---

为了完整起见，您还可以在克隆 repo 时进行深度设置：git clone -b <branch> <pathToRepo> --depth=<numCommitsWanted>

【讨论】：

我的本地仓库设置如下：mkdir newRepo; cd newRepo 然后git init THEN git remote add...

所以我尝试了这个，但它似乎不适用于我的情况（请参阅问题中的其他信息）。你提到了一个 --bare repo - 这有什么关系吗？有什么想法为什么它不只拉一小部分增量？

我只是在一个没有作为裸仓库启动的原始仓库上尝试了整个过程，但我仍然可以毫无问题地使用相同的过程。我仍然只拉下初始分支 + 1 次提交历史，如果我在使用 --depth=1 进行第一次拉后尝试执行git pull origin <branch> RIGHT，它会显示“已经更新到 tp-date”。当我对原始仓库进行一些提交（从其他地方推送）并执行git pull origin <branch> 时，我只会得到新的提交，而不是更多的历史......

git clone -b <branch> file://<pathToRepo> --depth=1 设法做与上述相同的事情，而且它自动将本地存储库与远程存储库链接起来......试试看。

好的，我今晚回家后一定会再试一次。再次感谢您的帮助！

【参考方案2】：

有几种方法可以减少带宽：

只克隆你需要的分支（--single-branch，这个只用于克隆，不能拉取；拉取时可以指定你需要的分支） 只克隆最新版本的文件（--depth 1，就像你做的那样）。这个默认暗示--single-branch。 只克隆你需要的文件（又名sparse checkout，比如here）

此外，如果拉取一直失败，我会使用这样的 bash 脚本不断重试，直到成功完成：

#!/bin/bash

until $( git pull --depth=1 origin master ); do        # <-- pull command goes here
    echo "Pulling repository failed; retrying..."
done

当然，在pull之前，你需要先初始化repo：

git init <dir>
cd <dir>
git remote add origin <repo_url>

【讨论】：

感谢您的说明——下次有需要我会尝试其中一些！

【参考方案3】：

这个“答案”只是我自己尝试解决这个问题失败的历史记录（尽管下面的克隆操作传输的数据少于当前的工作解决方案。）

---

第一次尝试失败：

第 1 部分。似乎最好通过以下方式解决：

与其使用 git 克隆整个仓库及其所有分支和历史记录，不如创建一个新的空仓库并获取我关心的一个深度为 1（无历史记录）的分支：

mkdir <project_name>
cd <project_name>
git init
git fetch --depth=1 <repo_url> <branchname>:refs/remotes/origin/<branchname>
git checkout <branchname>

这很棒，因为它执行的网络传输比完整的 git clone 或 pull 小得多。

但是现在我遇到了第 2 部分）从这个浅层存储库中拉取和推送的问题。我的同事和我一样全天都在进行小更新，因此应该可以快速拉出和推送这些小的增量更改。但是当我尝试将分支设置为跟踪远程时， git pull 会尝试提取完整的历史记录。即使使用 --depth 1 运行 pull 或 fetch 似乎也想再次传输整个快照（而不是小的增量更改）。

那么在这种情况下我该怎么办？ （除了显而易见的 - 清理 repo，删除旧的历史项目和死分支。）

第二次失败的尝试（根据@g19fanatic 下面的建议）：

按照@g19fanatic 的建议，我使用创建了一个 repo

> mkdir <project_name>
> cd <project_name>
> git init
> git remote add origin <repo_url>
> git pull origin <branchname> --depth=1
remote: Counting objects: 9403, done.
remote: Compressing objects: 100% (6675/6675), done.
remote: Total 9403 (delta 2806), reused 7217 (delta 2136)
Receiving objects: 100% (9404/9403), 325.63 MiB | 206 KiB/s, done.
Resolving deltas: 100% (2806/2806), done.
...

这创建了一个跟踪分支，并且仅正确提取了 1 个分支的历史记录（约 9400 个对象，325MB，而完整的 repo 为约 46k 个对象）。但是，再一次，如果不提取比我认为需要提取的更多信息，我似乎无法 git pull。我认为我应该能够将我的同事提交到几个对象和几千字节中。但这是我看到的：

> git pull origin <branchname>
remote: Counting objects: 45028, done.
remote: Compressing objects: ... ^C

这将拉取整个 repo 中的所有对象，所以我把它弄坏了。我尝试使用 --depth=1 参数进行拉动：

> git pull origin <branchname> --depth=1
remote: Counting objects: 9870, done.
remote: Compressing objects: 100% (7045/7045), done.
Receiving objects:   4% (430/9870), 4.20 MiB | 186 KiB/s ^C

9k+ 个对象将类似于最初的拉取，但我给出了一点，因为我认为其中一些对象可能已经存在于本地。但是，在它传输了 4+ MB 之后，我打破了这个命令，因为它似乎再次进行了整个传输。请记住，我希望我的同事能提供小的更新，而且我没有时间每次都提取 300MB。