Обидва способи зменшують обсяг завантаження, але обрізають різні речі.
Поверхневий клон (--depth 1) обрізає історію: комітів до певної глибини просто немає.
Частковий клон (--filter) завантажує всю історію комітів, але не всі об'єкти - пропущені догружаються з сервера на вимогу:
git clone --filter=blob:none https://github.com/acme/app.git # blobless
git clone --filter=tree:0 https://github.com/acme/app.git # treeless
git clone --filter=blob:limit=1m https://github.com/acme/app.git # без файлів понад 1 МБ
| Поверхневий | Без blob-ів (blob:none) |
Без дерев (tree:0) |
|
|---|---|---|---|
| коміти | лише останні | усі | усі |
| дерева (каталоги) | лише останні | усі | на вимогу |
| вміст файлів | лише останні | лише для checkout, решта на вимогу | на вимогу |
git log |
обрізаний | повний | повний |
git log -p, blame |
обмежені | працюють, догружаючи файли | повільні, багато догрузок |
| для кого | CI, одноразові збирання | розробники | CI, якому потрібна історія комітів |
Чому blobless клон - добрий вибір для розробника великого репозиторію:
- історія повна:
log,merge-base,describe, перемикання гілок працюють як звичайно; - старі версії великих файлів не завантажуються, поки не знадобляться;
git blameчи перегляд старого коміту догружають потрібні об'єкти - помітна, але одноразова затримка.
Чому поверхневий клон - для CI: найменший обсяг і жодних мережевих запитів пізніше. Але все, що потребує історії, не працює.
Treeless клон економить найбільше серед часткових, але операції з історією файлів роблять багато запитів до сервера - для щоденної роботи зазвичай повільно.
Що потрібно:
- підтримка на сервері (GitHub, GitLab, Bitbucket підтримують);
- доступ до сервера при операціях, що потребують відсутніх об'єктів - офлайн частина команд не працюватиме;
- не поєднувати бездумно з
--depth- зазвичай обирають одне.
Разом зі sparse-checkout частковий клон дає найкращий ефект для монорепозиторію: не завантажуються ні старі версії, ні файли з чужих каталогів.
Докладніше в документації: GitHub Blog: partial clone і shallow clone