L’avenir des fichiers volumineux dans Git, c’est Git lui-même

• Le projet Git a récemment commencé officiellement à s’attaquer directement au problème de la gestion des fichiers volumineux
• Git LFS est une solution de contournement provisoire qui entraîne pour les utilisateurs plusieurs coûts et une dépendance vis-à-vis d’un fournisseur
• Grâce à la fonctionnalité récente de partial clone, Git seul peut désormais remplacer la plupart des usages de LFS
• À l’avenir, une nouvelle solution appelée large object promisor est également en préparation pour être intégrée à Git officiel
• Avec ces évolutions, la solution ultime à la gestion des fichiers volumineux devrait converger non pas vers une extension externe, mais vers Git lui-même

---

Le problème des fichiers volumineux dans Git et son évolution

• Si Git a un plus grand ennemi, ce sont bien les fichiers volumineux
• Les fichiers volumineux font enfler les dépôts Git, ralentissent git clone et affectent négativement la plupart des environnements d’hébergement

L’arrivée de Git LFS et ses limites

• En 2015, GitHub a lancé Git LFS pour contourner le problème des fichiers volumineux
• Mais Git LFS ajoute lui-même une nouvelle complexité ainsi que des coûts de stockage supplémentaires

• La communauté Git réfléchit discrètement depuis longtemps au problème de fond des fichiers volumineux, et les récentes versions officielles de Git proposent désormais une nouvelle direction pour les gérer sans LFS

Ce qu’on peut faire dès aujourd’hui : remplacer Git LFS par partial clone

• Principe de partial clone

  • Git LFS : les fichiers volumineux sont placés en dehors du dépôt, et l’on travaille en ne téléchargeant que les fichiers nécessaires
  • Git partial clone (introduit en 2017) :
    • clonage en excluant les blobs au-dessus d’une certaine taille via l’option --filter
    • téléchargement depuis le serveur uniquement des fichiers volumineux nécessaires au moment où ils sont requis
      > L’utilisation de Partial clone permet de ne pas télécharger à l’avance [des assets binaires volumineux] pendant le clone et le fetch, ce qui réduit le temps de téléchargement et l’utilisation disque
      > - Partial Clone Design Notes, git-scm.com

• Points communs entre partial clone et LFS

  • 1. Réduction de la taille du checkout : seule la version la plus récente est récupérée, sans l’historique complet des fichiers
  • 2. Clonage rapide : l’absence de transfert de fichiers volumineux accélère le clone
  • 3. Mise en place rapide : contrairement à un shallow clone, on conserve l’accès à tout l’historique du projet

• Exemple d’utilisation de partial clone

  • Exemple concret de vitesse de clonage et d’espace disque pour un repo contenant un long historique de gros fichiers PNG :
    • avec un clone classique : presque 4 minutes et 1,3 Go occupés
    • avec partial clone et une limite de blob de 100 KB : clonage en 6 secondes et 49 Mo occupés
    • soit une amélioration de 97 % de la vitesse de clonage et une réduction de 96 % de la taille du checkout par rapport à l’original

• Limites de partial clone

  • lorsque les données filtrées sont nécessaires (par ex. git diff, git blame, git checkout), Git demande les fichiers au serveur
  • c’est une caractéristique identique à Git LFS
  • en pratique, il est rare d’avoir besoin d’utiliser blame sur des fichiers binaires

Les problèmes de Git LFS

• Forte dépendance fournisseur : l’implémentation de GitHub ne prend en charge que ses propres serveurs, ce qui entraîne facturation et dépendance
• Question de coût : pour 50 Go de stockage, GitHub LFS coûte 40 $ par an, contre 13 $ pour Amazon S3
• Retour en arrière difficile : une fois la migration vers LFS effectuée, il est impossible de revenir à l’état initial sans réécrire l’historique
• Coût de configuration permanent : tous les collaborateurs doivent installer LFS ; sinon, ils obtiennent des fichiers de métadonnées à la place des vrais fichiers, ce qui crée de la confusion

Perspectives : Large Object Promisor

• Les fichiers volumineux posent aussi un problème de coût pour les plateformes d’hébergement comme GitHub et GitLab
• Git LFS réduit les coûts serveur en déportant les fichiers volumineux vers un CDN

• Qu’est-ce que Large Object Promisor ?

  • plus tôt cette année, Git a officiellement fusionné une fonctionnalité appelée large object promisor
  • cette fonctionnalité réduit, comme LFS, la charge de stockage côté serveur, tout en diminuant fortement la complexité côté utilisateur
    > Cet effort vise à améliorer le travail côté serveur, en particulier sur les gros blobs déjà compressés en format binaire
    > Il s’agit d’une solution alternative à Git LFS
    > – Large Object Promisors, git-scm.com

• Principe de fonctionnement

  • 1. l’utilisateur pousse un fichier volumineux vers l’hôte Git
  • 2. l’hôte déporte ce fichier volumineux vers un promisor backend
  • 3. lors du clone, l’hôte Git fournit au client les informations du promisor
  • 4. le client récupère automatiquement le fichier volumineux depuis ce promisor si nécessaire

• État actuel de l’adoption et défis

  • le promisor pour objets volumineux est encore en cours de développement, et une partie du code a été fusionnée dans Git en mars 2025
  • des implémentations supplémentaires et des discussions sur les problèmes non résolus sont en cours, notamment chez GitLab
  • son adoption à grande échelle demandera encore du temps
  • à court terme, la dépendance à Git LFS pour stocker des fichiers volumineux reste inévitable
  • si le promisor se généralise, il devrait devenir possible de téléverser sur GitHub des fichiers de plus de 100 Mo

Conclusion : l’avenir des fichiers volumineux dans Git, c’est Git

• Le projet Git réfléchit sans relâche au problème des fichiers volumineux à votre place
• Pour l’instant, l’usage de Git LFS reste nécessaire
• Mais à mesure que partial clone et large object promisors progressent, Git LFS deviendra progressivement superflu, et l’on entrera bientôt dans une ère où il sera facile de gérer des fichiers volumineux avec Git seul
• À l’avenir, la dernière barrière à l’usage de gros fichiers dans Git sera peut-être simplement l’idée d’y mettre une bibliothèque de MP3