Git Shallow Clone и Clone Depth

Общие сведения о Git Shallow Clone и Clone Depth

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

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

Git Shallow Clone and Size

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

$ git clone https://github.com/django/django.git

Клонирование в ‘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 —depth 1 https://github.com/django/django.git

Клонирование в ‘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 and History

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

$ mkdir _example
$ cd _example
$ ls
$ git init
Инициализированный пустой репозиторий Git в/Users/zakh/git_repo/_example/.git/
$ echo x> large_file
$ git add -A
$ git commit -m «Начальная фиксация»
[master (root-commit) dd11686] Начальная фиксация
1 файл изменен, 1 вставка (+)
режим создания 100644 large_file

$ echo xx> large_file
$ git add -A
$ git commit -m «Модификация большого_файла 1»
[master 9efa367] Модификация большого_файла 1
1 файл изменен, 1 вставка (+), 1 удаление (-)

……….
…….. ..

$ mkdir test
$ cd test
$ git clone file:////Users/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 Модификация большого_файла 10
648d8c9 Модификация большого_файла 9
772547a Модификация большого_файла 8
13dd9ab Модификация большого_файла 7
5e73b67 Модификация большого_файла 6
030a6e7 Модификация большого_файла 5
1d14922 Модификация большого_файла 4
bc0f2c2 Модификация большого_файла 3
2794f11 Модификация большого_файла 2
d4374fb Модификация большого_файла 1
924829d Начальная фиксация

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

$ git clone —depth 1 file:////Users/zakh/git_repo/_example

Клонирование в ‘_example’ …
удаленное: подсчет объектов: 3, готово.
удаленное: сжатие объектов: 100% (2/2), готово.
удаленный: Всего 3 (дельта 0), повторно 0 (дельта 0)
Получение объектов: 100% (3/3), 50,02 МиБ | 65,12 Мбайт/с, готово.
Проверка подключения … выполнено.

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

$ git log —oneline

7fa451f Модификация большого_файла 10

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

$ git clone —depth 3 file:////Users/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 Изменение большого_файла 8

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

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

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

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

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

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

$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/ origin/master

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

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

$ git clone —depth 1 —no-single-branch https://github.com/django/django.git

Клонирование в ‘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 django

124M django

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

$ cd django
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/attic/boulder-oracle-sprint
remotes/origin/attic/full- история
remotes/origin/attic/generic-auth
remotes/origin/attic/gis
remotes/origin/attic/i18n
remotes/origin/attic/ магическое удаление
remotes/origin/attic/multi-auth
remotes/origin/attic/multiple-db-support
remotes/origin/attic/new-admin
remotes/origin/attic/newforms-admin
remotes/origin/attic/per-object-permissions
remotes/origin/attic/queryset-refactor
remotes/origin/ attic/schema-evolution
remotes/origin/attic/schema-evolution-ng
remotes/origin/attic/search-api
remotes/origin/attic/sqlalchemy
remotes/origin/attic/unicode
remotes/origin/master
remotes/origin/soc2009/admin-ui
remotes/origin/soc2009/http-wsgi-улучшения
remote/origin/s oc2009/i18n-sizes
remotes/origin/soc2009/model-validation
remotes/origin/soc2009/multidb
remotes/origin/soc2009/test-extensions
Remote/origin/soc2010/app-loading
remotes/origin/soc2010/query-refactor
remotes/origin/soc2010/test-refactor
remotes/origin/stable/0.90. x
remotes/origin/stable/0.91.x
remotes/origin/stable/0.95.x
remotes/origin/stable/0.96.x
remotes/ origin/stable/1.0.x
remotes/origin/stable/1.1.x
remotes/origin/stable/1.10.x
remotes/origin/stable/1.11.x
remotes/origin/stable/1.2.x
remotes/origin/stable/1.3.x
remotes/origin/stable/1.4.x
remotes/origin/ stable/1.5.x
remotes/origin/stable/1.6.x
remotes/origin/stable/1.7.x
remotes/origin/stable/1.8.x
remotes/origin/stable/1.9.x
remotes/origin/stable/2.0.x

Резюме

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

Ссылки:

  • git -clones-vs-shallow-git-clones/
  • community.atlassian.com => clone-depth-does-what-Why-do-I-care-about-this-setting/
  • git-scm.com/docs/git-clone
  • jenkins.io => large-git-repos.pdf
  • medium .com/@ wdyluis => git-gc-and-git-shallow-clone
  • stackoverflow.com => git-clone-by-default-shallow-or-not
  • unix.stackexchange.com => linux-kernel-source-code-size-difference
  • atlassian.com => handle-big-repositories-git
  • perforce.com => git -yond-basics-using-shallow-clones
Оцените статью
nanomode.ru
Добавить комментарий