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

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

23 голосов
/ 18 ноября 2011

У меня есть ситуация с относительно большим Git-репозиторием, расположенным на старом медленном хосте в моей локальной сети, где для первоначального клонирования требуется много времени. 

ravn@bamboo:~/git$ git clone gitosis@gitbox:git00
Initialized empty Git repository in /home/ravn/git/git00/.git/
remote: Counting objects: 89973, done.
remote: Compressing objects: 100% (26745/26745), done.
remote: Total 89973 (delta 50970), reused 85013 (delta 47798)
Receiving objects: 100% (89973/89973), 349.86 MiB | 2.25 MiB/s, done.
Resolving deltas: 100% (50970/50970), done.
Checking out files: 100% (11722/11722), done.
ravn@bamboo:~/git$

Нет никаких специфических изменений в gitosis.

Есть ли способ ускорить приемный бит до того, на что способна сеть?

РЕДАКТИРОВАТЬ: мне нужно, чтобы новые хранилища были правильно связаны с вышестоящим хранилищем. Насколько я понимаю, это требует, чтобы git выполнял клонирование, и поэтому копирование битов за пределы git не будет работать.

Ответы [ 6 ]

28 голосов
/ 18 ноября 2011

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

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

О различных других способах синхронизации репо переполненных см., Например,

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

Тупая копия

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

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

Плюс, вы получите

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

Bundle

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

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

Если вам нужен быстрый клон без затрат на стороне сервера, git way - это 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, когда вы решите это сделать!

24 голосов
/ 06 июня 2014

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

git clone --depth 1 <repository>
4 голосов
/ 21 ноября 2011

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

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

Другими словами, проблема была не в git, а в основном «железе».

1 голос
/ 02 мая 2019

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

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

git clone --recursive --shallow-submodules --depth 1 --branch "your tag or branch" --jobs 5 --  "your remote repo"
1 голос
/ 18 ноября 2011

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

0 голосов
/ 13 мая 2019

Предложение 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% быстрее!

...