Каков самый быстрый способ клонирования репозитория git через быстрое сетевое соединение?

Ответ 1

Поняв, что верхний предел скорости передачи данных является ssh-соединением, которое установлено "снаружи" из git, я сделал несколько экспериментов и обнаружил, что верхний предел использования pcsp (Putty scp) равен 3, 0 МБ/с, поскольку схема шифрования blowfish была выбрана правильно. Контрольный эксперимент с raw ftp показал, что скорость передачи составляет 3,1 МБ/с, поэтому он указал, что это была верхняя граница сети.

Это выполняется внутри гипервизора vmware, и поскольку процесс, выполняющий сетевой ввод-вывод, использует почти 100% -ный процессор, он указал, что узким местом является драйвер сетевой карты Ubuntu. Затем я обнаружил, что, хотя инструменты vmware были установлены, по какой-то причине ядро ​​по-прежнему использовало драйвер vlance (эмуляцию сетевой карты 10 Мбит/с с IRQ и все) вместо драйвера vmxnet (который говорит непосредственно с гипервизором). Это теперь ожидает изменение служебного окна.

Другими словами, проблема заключалась не в git, а в базовом "аппаратном обеспечении".

Ответ 2

PS. Справедливое предупреждение:

git обычно считается невероятно быстрым. Вы должны попробовать клонировать полное репо из darcs, bazaar, hg (бог запрещать: TFS или подрывная деятельность...). Кроме того, если вы регулярно клонируете полные репозитории с нуля, вы все равно будете делать что-то неправильно. Вы всегда можете просто git remote update и получить инкрементные изменения.

Для других способов сохранения полных репозиций см., например,

• "fetch -all" в git голом репозитории не синхронизируются локальные ветки с удаленными
• Как обновить клон git --mirror?

(ссылки содержат ссылки на другие соответствующие сообщения SO)

Dumb copy

Как уже упоминалось, вы можете просто скопировать репозиторий с переводом файла 'dumb'.

Это, безусловно, не будет тратить время на сжатие, переупаковку, дефиницию и/или фильтрацию.

Кроме того, вы получите

• Крючки
• config (пульты, push-ветки, настройки (пробелы, слияние, псевдонимы, данные пользователя и т.д.)
• stashes _{^{(см. Могу ли я получить кошелек из удаленного репо в локальную ветку?)}}
• rerere cache
• reflogs
• резервные копии (от ветки фильтра, например) и другие другие вещи (промежуточное состояние от rebase, bisect и т.д.).

Это может быть или не быть тем, что вам нужно, но приятно быть в курсе факта

Bundle

Git клон по умолчанию оптимизирует пропускную способность. Поскольку клон git по умолчанию не отражает все ветки (см. --mirror), было бы бессмысленно просто выгружать пакетные файлы as-is (потому что это отправит, возможно, больше, чем требуется).

При распределении к действительно большому числу клиентов рассмотрим использование пакетов.

Если вам нужен быстрый клон без затрат на сервер, путь git bundle create. Теперь вы можете распространять пакет, без участия сервера. Если вы имеете в виду, что bundle... --all содержит больше, чем просто git clone, рассмотрите, например, bundle ... master, чтобы уменьшить громкость.

git bundle create snapshot.bundle --all # (or mention specific ref names instead of --all)

и вместо этого распределите пакет снимков. Это лучшее из обоих миров, хотя, конечно, вы не получите предметы из списка маркеров выше. На принимающей стороне просто

git clone snapshot.bundle myclonedir/

Конфигурации сжатия

Вы можете посмотреть снижение нагрузки на сервер путем уменьшения/удаления сжатия. Посмотрите на эти настройки конфигурации (я предполагаю, что pack.compression может помочь вам снизить нагрузку на сервер)

^{core.compression}

Целое число -1..9, указывающее уровень сжатия по умолчанию. -1 - значение zlib по умолчанию. 0 означает отсутствие сжатия, а 1..9 - различные компромиссы скорости/размера, 9 - самые медленные. Если установлено, это предоставляет по умолчанию другие переменные сжатия, такие как core.loosecompression и pack.compression.

^{core.loosecompression}

Целое число -1..9, указывающее уровень сжатия для объектов, которые не находятся в файле пакета. -1 - значение zlib по умолчанию. 0 означает отсутствие сжатия, а 1..9 - различные компромиссы скорости/размера, 9 - самые медленные. Если не установлено, по умолчанию используется значение core.compression. Если это не установлено, значение по умолчанию равно 1 (лучшая скорость).

^{pack.compression}

Целое число -1..9, указывающее уровень сжатия для объектов в файле пакета. -1 - значение zlib по умолчанию. 0 означает отсутствие сжатия, а 1..9 - различные компромиссы скорости/размера, 9 - самые медленные. Если не задано, по умолчанию используется значение core.compression. Если это не установлен, по умолчанию используется значение -1, значение zlib по умолчанию, которое является "компрометацией по умолчанию между скоростью и сжатием (в настоящее время эквивалентно уровню 6)".

Обратите внимание, что изменение уровня сжатия не приведет к автоматическому повторному сжатию всех существующих объектов. Вы можете принудительно выполнить рекомпрессию, передав параметр -F в git -repack (1).

Учитывая достаточную пропускную способность сети, на самом деле это приведет к более быстрым клонам. Не забывайте о git-repack -F, когда вы решите проверить это!

Ответ 3

Используйте глубину, чтобы создать мелкий клон.

git clone --depth 1 <repository>

Ответ 4

Из журнала, похоже, вы уже закончили клон, если ваша проблема заключается в том, что вам нужно сделать этот процесс несколько раз на разных компьютерах, вы можете просто скопировать каталог репозитория с одного компьютера на другой. Таким образом, сохраняются отношения (удаленные объекты) между каждой копией и клонированным хранилищем.

Ответ 5

Я на скамейке отмечаю мерзавца-клона.

Это может быть быстрее с опциями --jobs, если проект включает подмодули, например:

git clone --recursive --shallow-submodules --depth 1 --branch "your tag or branch" --jobs 5 --  "your remote repo"

Ответ 6

git clone --depth=1... предложенный в 2014 году, станет быстрее во втором квартале 2019 года с Git 2.22.
Это связано с тем, что во время первоначального частичного клона " git clone --depth=... " бессмысленно тратить циклы на большую часть проверки связности, которая перечисляет и пропускает объекты промисора (которые по определению являются всеми объектами, извлеченными из Обратная сторона).
Это было оптимизировано.

clone: сделать быструю проверку объектов на частичные клоны

Для частичных клонов выполнение полной проверки подключения бесполезно; мы пропускаем объекты промисора (для частичного клона это все известные объекты), и перечисление их всех для исключения их из проверки подключения может занять значительное время на больших репозиториях.

Самое большее, мы хотим убедиться, что мы получаем объекты, на которые ссылаются любые разыскиваемые ссылки.
Для частичных клонов просто убедитесь, что эти объекты были перенесены.

Результат:

  Test                          dfa33a2^         dfa33a2
  -------------------------------------------------------------------------
  5600.2: clone without blobs   18.41(22.72+1.09)   6.83(11.65+0.50) -62.9%
  5600.3: checkout of result    1.82(3.24+0.26)     1.84(3.24+0.26) +1.1%

На 62% быстрее!