Git Shallow Clone и Clone Depth

Понимание Git Shallow Clone и Clone Depth

Git - это распределенная система контроля версий. Это одно из преимуществ использования Git. Вам не нужно зависеть от центрального сервера или репозитория для локальной работы. Все, что вам нужно относительно истории модулей, всегда у вас под рукой. Однако это может стать проблемой, когда вы имеете дело с репозиториями с большими двоичными файлами или репозиториями с долгой историей. Особенно, если у вас есть ситуация, когда вам нужно каждый раз загружать его свежим, например, сервер сборки, тогда размер и время загрузки могут стать проблемой.

Решением проблемы Git является неглубокий клон, где вы можете использовать глубину клона, чтобы определить, насколько глубоко должен идти ваш клон. Например, если вы используете -depth 1, то во время клонирования Git получит только последнюю копию соответствующих файлов. Это может сэкономить вам много места и времени.

Git Shallow Clone и размер

Давайте посмотрим на популярный репозиторий Git для Django. Если вы полностью клонируете репо, вы получите следующее:

$ git clone https: // github.com / django / django.мерзавец
Клонирование в django…
удаленный: Подсчет объектов: 409053, выполнено.
удаленный: Сжатие объектов: 100% (26/26), готово.
удаленный: всего 409053 (дельта 6), повторно используется 8 (дельта 1), повторно используется пакет 409026
Прием объектов: 100% (409053/409053), 167.77 МБ | 5.95 Мбайт / с, готово.
Разрешение дельт: 100% (297045/297045), выполнено.
Проверка подключения… выполнено.
Проверка файлов: 100% (5860/5860), готово.

Теперь, если вы проверите размер вашей локальной копии, это будет:

$ du -sh django /
225M django /

Получим тот же репозиторий Django с мелким клоном:

$ git clone - глубина 1 https: // github.com / django / django.мерзавец
Клонирование в django…
удаленный: Подсчет объектов: 8091, готово.
удаленный: Сжатие объектов: 100% (4995/4995), выполнено.
удаленный: всего 8091 (дельта 2036), повторно используется 5507 (дельта 1833), повторно используется пакет 0
Получение предметов: 100% (8091/8091), 8.82 МБ | 3.29 Мбайт / с, готово.
Устранение дельт: 100% (2036/2036), выполнено.
Проверка подключения… выполнено.
Проверка файлов: 100% (5860/5860), готово.

Теперь, если вы проверите размер вашей локальной копии, он должен быть значительно меньше:

$ du -sh django /
55M django /

Когда ваш сервер имеет дело с сотнями продуктовых линеек, такая экономия места на жестком диске может быть полезной. В случае игровых проектов, где есть тяжелые двоичные файлы, это может иметь драматический эффект. Это также помогает в долгосрочных проектах. Например, полное клонирование репозитория Linux из GitHub занимает более 7 ГБ, но вы можете неглубоко клонировать его менее 1 ГБ.

Git Shallow Clone и история

Вы можете локально проверить неглубокое клонирование с помощью собственного репозитория. Создадим файл в нашем локальном репозитории, внесем изменения и 10 раз зафиксируем. А затем мы можем клонировать репозиторий:

$ mkdir _example
$ cd _example
$ ls
$ git init
Инициализированный пустой репозиторий Git в / Users / zakh / git_repo / _example /.git /
$ echo x> большой_файл
$ git add -A
$ git commit -m "Начальная фиксация"
[master (root-commit) dd11686] Начальная фиксация
1 файл изменен, 1 вставка (+)
режим создания 100644 large_file
$ echo xx> большой_файл
$ git add -A
$ git commit -m "Изменение большого_файла 1"
[master 9efa367] Модификация large_file 1
1 файл изменен, 1 вставка (+), 1 удаление (-)
…
…
$ mkdir тест
$ cd test
$ git clone file: //// Пользователи / zakh / git_repo / _example
Клонирование в _example…
удаленный: Подсчет объектов: 33, готово.
удаленный: Сжатие объектов: 100% (22/22), готово.
удаленный: всего 33 (дельта 10), повторно используется 0 (дельта 0)
Получение предметов: 100% (33/33), 50.03 МиБ | 42.10 МБ / с, готово.
Разрешение дельт: 100% (10/10), выполнено.
Проверка подключения… выполнено.

В этом примере мы создали репозиторий _example git в папке / Users / zakh / git_repo / с одним large_file. Показаны только первые два коммита. Затем мы создаем полный клон этого репозитория в другом месте.

Тогда давайте проверим историю наших коммитов:

$ git log --oneline
7fa451f Модификация large_file 10
648d8c9 Модификация large_file 9
772547a Модификация large_file 8
13dd9ab Модификация large_file 7
5e73b67 Модификация large_file 6
030a6e7 Модификация large_file 5
1d14922 Модификация large_file 4
bc0f2c2 Модификация large_file 3
2794f11 Модификация large_file 2
d4374fb Модификация large_file 1
924829d Начальная фиксация

Мы видим все коммиты в полном клоне.
Теперь давайте удалим текущую копию, а затем неглубокий клон с глубиной 1:

$ git clone --depth 1 файл: //// Пользователи / zakh / git_repo / _example
Клонирование в _example…
удаленный: Подсчет объектов: 3, готово.
удаленный: сжатие объектов: 100% (2/2), готово.
удаленный: всего 3 (дельта 0), повторно используется 0 (дельта 0)
Получение предметов: 100% (3/3), 50.02 МиБ | 65.12 МБ / с, готово.
Проверка подключения… выполнено.

Если мы посмотрим на историю сейчас, мы увидим только последнюю историю коммитов:

$ git log --oneline
7fa451f Модификация large_file 10

Давайте неглубоко клонируем глубиной 3:

$ git clone --depth 3 file: //// Пользователи / zakh / git_repo / _example
Клонирование в _example…
удаленный: Подсчет объектов: 9, готово.
удаленный: сжатие объектов: 100% (6/6), готово.
удаленный: всего 9 (дельта 2), повторно используется 0 (дельта 0)
Получение предметов: 100% (9/9), 50.02 МиБ | 65.15 МБ / с, готово.
Разрешение дельт: 100% (2/2), выполнено.
Проверка подключения… выполнено.

Теперь мы видим больше коммитов:

$ git log --oneline
7fa451f Модификация large_file 10
648d8c9 Модификация large_file 9
772547a Модификация large_file 8

Проблемы с Git Shallow Clone

Пользователи должны понимать, что размер и экономия времени на загрузку зависят от организации коммитов. Они могут существенно отличаться от одного репозитория к другому. Хорошая идея - протестировать репозиторий с мелким клоном, чтобы проверить, сколько места на жестком диске и время загрузки он сэкономит вам.

Еще одно соображение заключается в том, что даже если вы можете отправить код из неглубокого клона, это может занять больше времени из-за вычислений между удаленным и локальным сервером. Поэтому, если вы регулярно коммитите код из локальной копии, вероятно, имеет смысл использовать полный клон.

Вариант с несколькими ветвями

Когда вы используете флаг -depth с командой clone, Git по умолчанию принимает флаг -single-branch. Но вы можете использовать флаг -no-single-branch, чтобы сообщить Git, что нужно получать истории из указанной глубины каждой ветки.

Вот ветки Django без опции -no-single-branch (глубина 1):

$ git branch -a
* владелец
удаленно / происхождение / ГОЛОВА -> происхождение / мастер
пульты / происхождение / мастер

Присутствует только главная ветка.

Вот ветки Django после использования опции -no-single-branch:

$ git clone --depth 1 --no-single-branch https: // github.com / django / django.мерзавец
Клонирование в django…
удаленный: Подсчет объектов: 95072, выполнено.
удаленный: Сжатие объектов: 100% (42524/42524), выполнено.
удаленный: всего 95072 (дельта 52343), повторно используется 82284 (дельта 42389), повторно используется пакет 0
Прием объектов: 100% (95072/95072), 74.69 Мбайт | 3.95 Мбайт / с, готово.
Разрешение дельт: 100% (52343/52343), выполнено.
Проверка подключения… выполнено.
Проверка файлов: 100% (5860/5860), готово.
$ du -sh джанго
124M джанго

Обратите внимание, хотя глубина все еще равна 1, размер клона составляет 124M вместо 55M в предыдущем случае.
Если мы проверим ветки, мы увидим намного больше веток на этом клоне:

$ cd django
$ git branch -a
* владелец
удаленно / происхождение / ГОЛОВА -> происхождение / мастер
удаленные / происхождение / чердак / валун-оракул-спринт
пульты / происхождение / чердак / полная история
пульты / происхождение / чердак / общий-auth
пульты / происхождение / чердак / гис
пульты / происхождение / чердак / i18n
пульты / происхождение / чердак / удаление магии
пульты / происхождение / чердак / мульти-авторизация
пульты / происхождение / чердак / поддержка нескольких БД
пульты / происхождение / чердак / новый администратор
пульты / происхождение / чердак / newforms-admin
удаленные / происхождение / чердак / разрешения для каждого объекта
удаленно / происхождение / чердак / запрос-рефакторинг
удаленные / происхождение / чердак / эволюция схемы
пульты / происхождение / чердак / схема-эволюция-нг
пульты / происхождение / чердак / поиск-api
пульты / происхождение / чердак / sqlalchemy
пульты / происхождение / чердак / юникод
пульты / происхождение / мастер
пульты / происхождение / soc2009 / админ-пользовательский интерфейс
удаленно / происхождение / soc2009 / http-wsgi-улучшения
пульты / происхождение / soc2009 / i18n-улучшения
пульты дистанционного управления / происхождение / soc2009 / проверка модели
пульты / происхождение / soc2009 / multidb
пульты / происхождение / soc2009 / тест-улучшения
пульты / происхождение / soc2010 / загрузка приложения
удаленно / происхождение / soc2010 / запрос-рефакторинг
удаленно / происхождение / soc2010 / тест-рефакторинг
пульты / происхождение / стабильный / 0.90.Икс
пульты / происхождение / стабильный / 0.91.Икс
пульты / происхождение / стабильный / 0.95.Икс
пульты / происхождение / стабильный / 0.96.Икс
пульты / происхождение / стабильный / 1.0.Икс
пульты / происхождение / стабильный / 1.1.Икс
пульты / происхождение / стабильный / 1.10.Икс
пульты / происхождение / стабильный / 1.11.Икс
пульты / происхождение / стабильный / 1.2.Икс
пульты / происхождение / стабильный / 1.3.Икс
пульты / происхождение / стабильный / 1.4.Икс
пульты / происхождение / стабильный / 1.5.Икс
пульты / происхождение / стабильный / 1.6.Икс
пульты / происхождение / стабильный / 1.7.Икс
пульты / происхождение / стабильный / 1.8.Икс
пульты / происхождение / стабильный / 1.9.Икс
пульты / происхождение / стабильный / 2.0.Икс

Резюме

Git shallow clone может помочь вам сэкономить время и место на жестком диске. Но это имеет свою цену. Если вы регулярно отправляете код в удаленные репозитории, это увеличит время фиксации. Итак, для обычных рабочих процессов рекомендуется избегать мелких клонов.