Phenquestions
Разбиране на Git Shallow Clone и Clone Depth
Git е разпределена система за контрол на версиите. Това е едно от предимствата на използването на Git. Не е нужно да разчитате на централен сървър или хранилище, за да работите локално. Всичко, от което се нуждаете по отношение на историята на вашите модули, е точно на върха на пръста ви. Това обаче може да се превърне в проблем, когато имате работа с хранилища с големи двоични файлове или хранилища с дълга история. Особено ако имате ситуация, при която трябва да го изтегляте свеж всеки път, като сървър за изграждане, тогава размерът и времето за изтегляне могат да се превърнат в проблем.
Решението на проблема на Git е плиткият клонинг, където можете да използвате дълбочината на клонирането, за да определите колко дълбоко трябва да стигне вашият клонинг. Например, ако използвате -depth 1, тогава по време на клонирането Git ще получи само най-новото копие на съответните файлове. Това може да ви спести много пространство и време.
Git Плитък клонинг и размер
Нека да разгледаме популярното хранилище на 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 MiB | 5.95 MiB / s, готово.
Разрешаване на делти: 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 MiB | 3.29 MiB / s, готово.
Разрешаване на делти: 100% (2036/2036), готово.
Проверка на свързаността ... готово.
Проверка на файлове: 100% (5860/5860), готово.
Сега, ако проверите размера на вашето локално копие, той трябва да бъде значително по-малък:
$ du -sh django /55M django /
Когато вашият сървър се занимава със стотици продуктови линии, този вид спестяване на място на твърдия диск може да бъде полезно. В случаите на игрови проекти, където има тежки двоични файлове, това може да има драматичен ефект. Помага и при дългогодишни проекти. Например, пълното клониране на хранилището на Linux от GitHub е повече от 7 GB, но можете да го клонирате плитко за по-малко от 1 GB.
Плитък клонинг и история
Можете да проверите локално плиткото клониране със собственото си хранилище. Нека създадем файл в нашето локално хранилище, направим промени и го ангажираме 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 голям_файл
$ echo xx> голям_файл
$ git add -A
$ git commit -m "Промяна в голям_файл 1"
[master 9efa367] Промяна на голям_файл 1
1 файл е променен, 1 вмъкване (+), 1 изтриване (-)
..
..
$ mkdir тест
$ cd тест
$ git clone file: //// Users / zakh / git_repo / _example
Клониране в „_example“ ..
дистанционно: Брой обекти: 33, готово.
дистанционно: Компресиране на обекти: 100% (22/22), готово.
дистанционно: Общо 33 (делта 10), повторно използвано 0 (делта 0)
Получаване на обекти: 100% (33/33), 50.03 MiB | 42.10 MiB / s, готово.
Разрешаване на делти: 100% (10/10), готово.
Проверка на свързаността ... готово.
В този пример създадохме хранилището _example git в папката / Users / zakh / git_repo / с един голям_файл. Показват се само първите две фиксирания. След това създаваме пълен клон на това хранилище на различно място.
Тогава нека проверим историята на нашите ангажименти:
$ git log --oneline7fa451f Промяна на голям_файл 10
648d8c9 Промяна на голям_файл 9
772547a Промяна на голям_файл 8
13dd9ab Промяна на голям_файл 7
5e73b67 Промяна на голям_файл 6
030a6e7 Промяна на голям_файл 5
1d14922 Промяна на голям_файл 4
bc0f2c2 Промяна на голям_файл 3
2794f11 Промяна на голям_файл 2
d4374fb Промяна на голям_файл 1
924829d Първоначален ангажимент
Виждаме всички ангажименти в пълния клонинг.
Сега нека изтрием текущото копие и след това плитък клонинг с дълбочина 1:
Клониране в „_example“ ..
дистанционно: Преброяване на обекти: 3, готово.
дистанционно: Компресиране на обекти: 100% (2/2), готово.
дистанционно: Общо 3 (делта 0), повторно използвано 0 (делта 0)
Получаване на обекти: 100% (3/3), 50.02 MiB | 65.12 MiB / s, готово.
Проверка на свързаността ... готово.
Ако разгледаме историята сега, виждаме само последната история на фиксиране:
$ git log --oneline7fa451f Промяна на голям_файл 10
Нека плитък клонинг с дълбочина 3:
$ git clone --depth 3 файл: //// Users / zakh / git_repo / _exampleКлониране в „_example“ ..
дистанционно: Преброяване на обекти: 9, готово.
дистанционно: Компресиране на обекти: 100% (6/6), готово.
дистанционно: Общо 9 (делта 2), повторно използвано 0 (делта 0)
Получаване на обекти: 100% (9/9), 50.02 MiB | 65.15 MiB / s, готово.
Разрешаване на делти: 100% (2/2), готово.
Проверка на свързаността ... готово.
Сега виждаме още ангажименти:
$ git log --oneline7fa451f Промяна на голям_файл 10
648d8c9 Промяна на голям_файл 9
772547a Промяна на голям_файл 8
Проблеми с Git Shallow Clone
Потребителите трябва да разберат, че спестяването на размер и време за изтегляне зависи от организацията на ангажиментите. Те могат значително да се различават от едно хранилище до друго. Добре е да тествате хранилището с плитък клонинг, за да проверите колко място на твърдия диск и времето за изтегляне ще ви спести.
Друго съображение е, че въпреки че можете да натиснете код от плитък клонинг, това може да отнеме повече време поради изчисленията между отдалеченото и локалния сървър. Така че, ако редовно ангажирате код от локалното копие, вероятно има смисъл да използвате пълен клонинг.
Опция за множество клонове
Когато използвате флага -depth с команда за клониране, Git по подразбиране приема флага -single-branch. Но можете да използвате флаг -no-single-branch, за да кажете на Git да получава истории от определената дълбочина на всеки клон.
Ето разклоненията на Django без опция -no-single-branch (дълбочина 1):
$ git клон -a* майстор
дистанционни / произход / HEAD -> произход / главен
дистанционни / произход / главен
Присъства само главният клон.
Ето разклоненията на 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 MiB | 3.95 MiB / s, готово.
Разрешаване на делти: 100% (52343/52343), готово.
Проверка на свързаността ... готово.
Проверка на файлове: 100% (5860/5860), готово.
$ du -sh django
124M джанго
Забележете, че въпреки че дълбочината е все още 1, размерът на клонинга е 124M вместо 55M за предишния случай.
Ако проверим клоновете, трябва да видим много повече клонове на този клон:
$ git клон -a
* майстор
дистанционни / произход / HEAD -> произход / главен
дистанционни / произход / таванско помещение / боулдър-оракул-спринт
дистанционни / произход / таванско помещение / пълна история
дистанционни / произход / таванско помещение / генерично удостоверяване
дистанционни / произход / таванско помещение / гис
дистанционни / произход / таванско помещение / i18n
дистанционни / произход / таванско помещение / магическо премахване
дистанционни / произход / таванско помещение / мулти-авт
дистанционно управление / произход / таванско помещение / поддръжка на множество db
дистанционно / произход / таванско помещение / нов администратор
дистанционно / произход / таванско помещение / newforms-admin
дистанционни / произход / таванско помещение / разрешения за обект
отдалечени / произход / таванско помещение / queryset-рефактор
дистанционни / произход / таванско помещение / еволюция на схемата
дистанционни / произход / таванско помещение / schema-evolution-ng
дистанционни / произход / таванско помещение / търсене-api
дистанционни / произход / таванско помещение / sqlalchemy
дистанционни / произход / таван / unicode
дистанционни / произход / главен
remotes / origin / soc2009 / admin-ui
remotes / origin / soc2009 / http-wsgi-подобрения
remotes / origin / soc2009 / i18n-подобрения
remotes / origin / soc2009 / проверка на модела
Remotes / origin / soc2009 / multidb
Remotes / origin / soc2009 / test-подобрения
remotes / origin / soc2010 / app-loading
remotes / origin / soc2010 / query-refactor
remotes / origin / soc2010 / test-refactor
дистанционни / произход / стабилни / 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 може да ви помогне да спестите време и място на твърдия диск. Но това си има цена. Ако редовно бутате код към отдалечени хранилища, това ще увеличи времето за фиксиране. Така че, за редовните работни потоци е добре да избягвате плитки клонинги.
Препратки:
- git-clones-vs-shallow-git-clones /
- общност.атласки.com => clone-deep-does-what-Why-do-I-care-about-this-setting /
- git-scm.com / docs / git-clone
- дженкини.io => large-git-repos.pdf
- средно.com / @ wdyluis => git-gc-и-git-плитка клонинг
- stackoverflow.com => git-clone-by-default-shallow-or-not
- unix.обмен на стекове.com => linux-kernel-source-code-size-razlika
- атласки.com => handle-big-repositories-git
- изпълнявам.com => git-отвъд основите-използване-плитки клонинги
