У великому монорепозиторії робочий каталог може містити сотні тисяч файлів, з яких розробнику потрібні кілька каталогів. Sparse-checkout лишає в робочому каталозі лише вказані шляхи - решта файлів є в історії, але не на диску.
git clone --filter=blob:none --sparse https://github.com/acme/monorepo.git
cd monorepo
git sparse-checkout set apps/billing packages/ui
git sparse-checkout add packages/auth
git sparse-checkout list
git sparse-checkout disable # повернути всі файли
Режим cone (за замовчуванням) - шаблони лише на рівні каталогів:
- до робочого каталогу потрапляють файли в корені репозиторію, вказані каталоги цілком і файли в їхніх батьківських каталогах (без вкладених підкаталогів);
- Git перевіряє шляхи значно швидше, ніж у режимі довільних шаблонів у стилі
.gitignore, тому для великих репозиторіїв cone рекомендований.
Що це дає:
git status,git checkout,git switchпрацюють з меншою кількістю файлів - значно швидше;- IDE індексує лише потрібний код;
- менше місця на диску.
Найкраще - разом з частковим клоном (--filter=blob:none): тоді вміст файлів поза sparse-набором навіть не завантажується з сервера.
Як інші операції поводяться з невидимими файлами:
- коміти, злиття й rebase працюють з усім деревом - Git знає про всі файли;
- конфлікт у файлі поза sparse-набором - Git тимчасово розміщує файл у робочому каталозі для розв'язання;
git grepіgit log -- pathможуть шукати й поза набором.
Типове застосування:
- монорепозиторій: розробник фронтенду бачить лише
apps/webі спільні пакети; - CI: збирання конкретного сервісу без виписування всього репозиторію - разом з
--depth 1і--filter; - документація в репозиторії з великим кодом.
Обмеження:
- інструменти, яким потрібні файли поза набором (наприклад, Composer з
path-репозиторіями на сусідні пакети, збирачі, що шукають конфіги в корені), ламаються - набір має містити всі залежності; - для невеликого проєкту накладні витрати не виправдані.