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

[GN⁺]

Commentaire Hacker News

• Même à l’époque de svn, un répertoire de travail de 150 Go contenant beaucoup de gros fichiers binaires fonctionnait sans vrai problème, alors que git ne s’en sort pas aussi bien. Je me demande pourquoi svn adopte une approche différente de git pour les gros fichiers binaires, et pourquoi git ne pourrait pas faire la même chose. En plus, une fonctionnalité indispensable lorsqu’on manipule des données binaires est le verrouillage de fichiers : une seule personne devrait pouvoir modifier un fichier, tandis que les autres resteraient en lecture seule, afin d’éviter des conflits de fusion ingérables. J’ai aussi du mal à comprendre en quoi déporter les gros fichiers ailleurs améliore réellement les performances ou la stabilité. Au final, ça reste un dépôt, simplement dans un autre dépôt. Ce déport ressemble surtout à un moyen pour les forges Git publiques d’éviter les coûts de stockage des gros fichiers

  • git et svn ont des conceptions totalement différentes. git est entièrement distribué, donc chaque dépôt doit posséder l’historique complet de tous les fichiers, et la notion de verrouillage n’y a pas vraiment de sens. Il faut choisir le système de gestion de versions adapté au projet ; git n’a pas vocation à tout faire

• J’aime bien l’idée des large object promisors. Si on pouvait facilement brancher un service comme S3, je pense que je quitterais immédiatement LFS. S3 a une vraie synergie avec le versionnage de gros fichiers binaires. Avec l’Intelligent-Tiering, les données basculent automatiquement vers des classes de stockage moins chères à mesure qu’elles vieillissent. Si je dois attendre une demi-journée pour restaurer des données vieilles de 10 ans, ça m’est égal

  • Je pense pareil. Je ne comprends pas pourquoi ça n’a pas été la solution par défaut dès le départ. J’héberge moi-même un petit serveur git LFS, et si git prenait nativement en charge S3, je serais prêt à migrer immédiatement

  • À mon travail actuel, nous mettons en cache les objets LFS dans un bucket pour réduire les coûts. À chaque exécution de PR, on récupère la liste des fichiers avec git lfs ls-files, on les télécharge depuis gcp, on stocke les objets localement avec git lfs checkout, puis on fait un pull pour ne récupérer que ce qui manque. Les fichiers non mis en cache sont renvoyés dans le bucket avec gcloud storage rsync. Côté développeur, aucune configuration supplémentaire n’est nécessaire : il suffit de pull les nouveaux objets, et l’interface GitHub ne montre rien de confus sur l’état du dépôt. Avant, on envisageait d’héberger nous-mêmes un backend LFS, mais cette méthode résout notre problème principal à court terme. GitHub facturait trop de bande passante à chaque récupération des fichiers LFS par la CI, et avec la limite de cache à 10 Go et l’impossibilité de partager entre branches, il fallait tout retélécharger à chaque fois. J’aurais même voulu pouvoir augmenter la taille du cache en payant, mais ce n’était pas possible. Pour appliquer ça aux développeurs, il suffit d’ajouter un hook git, donc c’est assez simple

  • Je me demande si S3 est un service lié à Amazon

• Je suis d’accord avec plusieurs critiques sur Git LFS, mais pas avec l’idée qu’il y aurait un vendor lock-in. GitHub fournit un client et un serveur open source, donc cet argument me paraît injustifié. En revanche, LFS ne fonctionne pas hors ligne ou en mode sneaker net, ce qui n’est pas un cas si courant, mais mérite d’être mentionné. Les large object promisors donnent l’impression de déplacer vers le serveur la complexité côté client de LFS ; au final, on dirait surtout que la complexité change de place. Si le serveur git envoie les fichiers vers un serveur LFS et un object store, cela introduit d’autres compromis. Je me demande aussi ce qui se passera quand des serveurs git publics masqueront des remotes promisor au moment des uploads

  • Je trouve que LFS est vraiment mauvais. L’implémentation serveur est bancale, et le contenu des objets est mélangé avec leur mode de stockage. Le mécanisme d’opt-in est aussi très mal conçu : si on l’utilise sans réfléchir, on se retrouve en fait avec un petit fichier texte à la place du vrai fichier attendu. Je ne sais pas si la nouvelle solution sera meilleure, mais une chose est sûre : LFS n’est pas bon

  • Un autre problème de Git LFS que j’ai découvert récemment, c’est que la migration pollue même les .gitattributes des commits ancêtres. Autrement dit, si dans une suite de commits A→B→C, un gros fichier n’a été ajouté à LFS qu’au commit C, alors A et B se retrouvent eux aussi avec des .gitattributes pointant vers des fichiers LFS inexistants. Pendant la migration, .gitattributes se propage à rebours dans l’historique, car le processus ne vérifie pas si l’entité référencée existe réellement dans le commit courant

  • Avant, Git LFS ne prenait pas SSH en charge, ce qui obligeait à obtenir un certificat SSL ; pour les gens qui s’auto-hébergeaient ça chez eux, c’était un vrai frein à l’entrée. Il semble que GitLab ait récemment ajouté un patch pour le support SSH

• En cours de génie logiciel, on nous recommandait de ne pas mettre les gros fichiers (médias, etc.) dans Git, mais dans un dépôt d’artefacts comme Artifactory. On pouvait alors les publier sous forme de dépendances snapshot, et le système de build se chargeait de ne récupérer automatiquement que la dernière version. Les anciens fichiers accumulés en local chez les collègues pouvaient aussi être nettoyés immédiatement en vidant simplement le cache du système de build

  • Cette approche ressemble un peu à une forme de submodule git. Si les submodules avaient vraiment résolu le problème, les gens les utiliseraient déjà. Les submodules git prennent aussi en charge les shallow clones (lien connexe : https://stackoverflow.com/questions/2144406/how-to-make-shallow-git-submodules). Je n’ai jamais eu de problème de gros fichiers, donc je me demande pourquoi cette méthode ne fonctionnerait pas. Les inconvénients mentionnés sur SO ne me paraissent pas si graves

  • Je me demande si le cours enseigne aussi l’architecture des systèmes CI/CD. Les jeunes ingénieurs aujourd’hui ne sont pas très familiers avec l’architecture globale qui relie GitLab, Artifactory, CodeSonar, Anchore, etc.

  • Cette méthode a aussi des inconvénients. Elle exige des informations d’authentification supplémentaires pour la CI/CD ou pour les développeurs. Les commits deviennent plus nombreux et plus compliqués, il faut connaître d’abord l’identifiant de l’artefact, et si on commence à automatiser cela avec des hooks git, on finit par retrouver une complexité proche de git-lfs

• Cet article juge LFS de manière injuste. LFS n’est pas dépendant de GitHub et son protocole est ouvert. Les défauts de LFS sont inévitables dès lors qu’il s’agit d’une extension de git, et les promisors relèvent en réalité pratiquement du même concept. La différence, c’est surtout une meilleure UX grâce à une intégration directe dans git

  • Un dépôt qui a utilisé LFS ne serait-ce qu’une fois reste verrouillé à vie. Pour réduire l’espace utilisé, il faut supprimer le dépôt lui-même, et ce n’est même pas clairement indiqué dans la documentation officielle. Notre entreprise a vécu ce problème en mettant de gros fichiers de base de données compressés dans LFS pour analyser les statistiques GitHub

• Ce n’est pas une vraie solution. git LFS n’est qu’un pansement temporaire, et même avec un argument de filtre au moment du clone, on ne règle pas le problème de fond. git clone est la première commande que tout le monde apprend, et si chacun doit se souvenir d’ajouter un filtre à chaque fois, on ne fait que perdre du temps ; et même quand ça marche, le dépôt cloné peut ne pas fonctionner correctement. Il faudra au final passer à un modèle plus proche de rsync, qui récupère efficacement d’abord les fichiers les plus récents. git ne fait pas facilement ce genre de changements de fond

  • Je suis tout à fait d’accord. git “résout” toujours les problèmes en ajoutant un drapeau de plus, mais la plupart des utilisateurs ignorent ces fonctionnalités. On pourrait améliorer les valeurs par défaut sans casser la compatibilité et ainsi réellement corriger le problème

  • le dépôt cloné peut ne pas fonctionner correctement
    En réalité, il ne manque que l’historique des blobs

  • On dit que rsync a résolu ce problème, mais à quoi cela ressemblerait-il concrètement ? Je ne parle pas de l’algorithme, mais de ce qui apparaîtrait réellement dans le système de fichiers local quand l’utilisateur fait un git clone

  • Si la majeure partie du volume du dépôt vient des révisions anciennes, alors une approche à la rsync, qui récupère d’abord uniquement la version la plus récente, est probablement la solution la plus adaptée pour la plupart des utilisateurs

• Je suis très heureux de voir arriver la prise en charge des gros fichiers dans le cœur de Git. Même avec une solution externe, on reste de toute façon dans une logique d’opt-in comparable. Je voulais réduire au maximum le nombre de commandes et rendre cela aussi seamless que possible, c’est pourquoi j’ai limité la conception de l’API aux seuls filtres smudge/clean du fichier .gitattributes. J’ai aussi travaillé directement avec Atlassian et Microsoft pour éliminer le vendor lock-in, et Atlassian a beaucoup aidé sur l’API de verrouillage de fichiers. LFS est proposé en open source avec une prise en charge compatible sur trois hébergeurs

• Nous développons oxen pour résoudre les problèmes que nous avons rencontrés avec git et git-lfs. L’interface suit celle de git, mais fonctionne bien plus rapidement avec les gros fichiers et dans des environnements monorepo contenant des millions de fichiers. Nous fournissons un CLI et un serveur open source ; si ça vous intéresse, vos retours sont bienvenus
  https://github.com/Oxen-AI/Oxen

• Le mode de stockage de git lui-même aurait besoin d’une refonte, à la manière des outils de sauvegarde modernes comme restic ou borg, avec du content-defined chunking pour les fichiers et les répertoires

• Parmi les défauts de GitLFS, il manque aussi les problèmes d’authentification : sans SSH-agent, il faut parfois s’authentifier plusieurs fois pour un seul push. D’après mon expérience, cela pouvait arriver deux ou trois fois, voire plus