Clone partiel et sparse checkout

Le couple partial clone + sparse checkout garde un vrai dépôt git, et n'écrit sur le disque que les chemins choisis.

Pourquoi est-ce intéressant/utile ?

Le gain se joue à deux endroits :

• le dossier de travail ne contient que les répertoires choisis
• Le contenu des fichiers n'est téléchargé que pour ces chemins, donc le .git reste plus léger.

L'historique reste complet : commits, branches, remote. log, pull et checkout se comportent comme sur un clone ordinaire. Élargir le checkout plus tard ne rapatrie que les fichiers manquants.

Usecases courants

• Quand on travaille sur une partie d'un monorepo
• Quand on travaille uniquement sur de la doc/ci par exemple

Utilisation

Partial clone

--filter=blob:none demande à git de récupérer les commits et l'arborescence et de laisser le contenu des fichiers (les blobs) sur le remote. Ces blobs arrivent au moment où une commande en a vraiment besoin, par exemple au moment du checkout d'un chemin.

Sparse checkout

--sparse, puis git sparse-checkout set, limite le dossier de travail aux chemins donnés. Le mode par défaut, cone, est un peu plus large que la liste exacte :

• les fichiers à la racine du dépôt sont inclus
• pour un chemin comme assets/docs, les fichiers posés directement dans assets/ le sont aussi

Les autres sous-dossiers restent absents du disque. Ils existent toujours dans l'historique.

En pratique

git clone --filter=blob:none --sparse git@github.com:user/repo.git my-working-folder
cd my-working-folder
git sparse-checkout set doc assets/docs

Voir ce qui est extrait :

git sparse-checkout list

set remplace la liste. add l'étend, et git télécharge les blobs correspondants :

git sparse-checkout add src/api

Pour retrouver un dossier de travail complet, ce qui déclenche le téléchargement du reste :

git sparse-checkout disable