Travailler dans un grand dépôt avec le sparse checkout et le clone partiel

Ce que c'est

Un dépôt unique regroupant de nombreux projets est lent à cloner et encombré à utiliser. Git propose trois réductions indépendantes :

• Le sparse checkout (git sparse-checkout set <dir>...) restreint les chemins matérialisés dans l'arbre de travail et l'index. La documentation décrit le mode cône, désormais le mode par défaut, où l'entrée est une liste de répertoires plutôt que des motifs à la gitignore ; le mode à motifs hors cône est explicitement déconseillé. --sparse-index réduit l'index en conséquence.
• Le clone partiel (git clone --filter=blob:none) demande au serveur d'omettre des objets selon un filtre ; blob:none omet tout le contenu des fichiers jusqu'à ce qu'il soit nécessaire, blob:limit=<size> n'omet que les blobs d'au moins cette taille. Les notes de conception expliquent que le dépôt distant devient un dépôt distant promisor, et que les objets manquants sont récupérés à la demande, ce qui exige d'être en ligne et, comme les objets sont récupérés un par un, « tend à être lent ».
• Le clone superficiel (--depth <n>) tronque l'historique. C'est un mécanisme différent, avec ses propres limites, et il n'est pas nécessaire pour faire fonctionner le clone partiel.

Pourquoi c'est important

Le temps de clonage, l'utilisation du disque et l'ampleur des analyses de git status croissent avec le dépôt entier, pas avec la partie que touche une personne ou une tâche de CI. Appliquer la bonne réduction transforme un checkout de plusieurs gigaoctets en une arborescence de répertoires adaptée à la tâche.

Comment l'appliquer

• Pour les développeurs : git clone --filter=blob:none --sparse <url> (l'option --sparse démarre avec seulement les fichiers de premier niveau), puis git sparse-checkout set services/api libs/common.
• Garder des répertoires entiers dans le cône ; les fichiers frères de chaque répertoire ancêtre sont inclus automatiquement, ce qui rend disponibles les fichiers de build situés à la racine.
• Pour les tâches de CI qui n'ont besoin que d'un commit : un clone partiel sans blob des chemins nécessaires, ou un clone superficiel lorsque l'historique n'a pas d'importance.
• Vérifier git sparse-checkout list lorsqu'un build ne trouve pas un fichier ; ajouter le répertoire plutôt que de désactiver le mode sparse.
• Les commandes qui parcourent l'historique (git log -p, git blame) déclenchent des récupérations à la demande dans un clone partiel ; les exécuter là où le réseau est rapide, ou pré-récupérer au préalable.

Pièges

Les outils qui analysent l'arbre de travail supposent que le dépôt entier est présent et peuvent signaler à tort des répertoires manquants. Les motifs hors cône cassent --sparse-index et sont lents. Un travail hors ligne dans un clone partiel échoue au premier blob manquant. Un clone superficiel ne peut répondre à aucune question d'historique au-delà de sa limite.