Git LFS vs. Git Standard : Performances pour les Actifs Volumineux

Git LFS vs. Git Standard : Implications de performance pour les gros actifs

Git, le système de contrôle de version distribué fondamental, excelle dans le suivi des changements dans le code source basé sur du texte. Son efficacité repose fortement sur le stockage adressé par contenu (content-addressed storage), qui utilise la compression delta pour gérer les changements petits et incrémentiels à travers l'historique. Cependant, ce modèle rencontre des obstacles de performance significatifs lorsqu'il est appliqué à de gros fichiers binaires, tels que des actifs multimédias, des textures de jeu ou de grands ensembles de données.

Pour les projets qui dépendent fortement de données non textuelles, l'utilisation de Git standard peut rapidement entraîner l'engorgement du dépôt (repository bloat), des temps de clonage lents et une inefficacité des ressources. Cet article propose une comparaison de performance complète entre Git standard et Git Large File Storage (LFS), détaillant les mécanismes de chacun et identifiant le moment où LFS devient l'outil d'optimisation nécessaire pour gérer efficacement les actifs massifs.

Le goulot d'étranglement de performance de Git standard

Pour comprendre pourquoi Git LFS existe, nous devons d'abord examiner comment Git standard gère les fichiers, et spécifiquement, pourquoi cette approche échoue pour les gros fichiers binaires.

Stockage adressé par contenu et historique

Le principe de conception fondamental de Git exige que chaque version de chaque fichier commis soit stockée dans l'historique du dépôt (le répertoire .git). Lorsqu'un dépôt est cloné, toutes les données historiques — y compris chaque version de chaque gros fichier binaire — sont transférées vers la machine locale.

Cette approche fonctionne mal pour les fichiers binaires pour deux raisons principales :

Compression Delta Inefficace : Les fichiers binaires (comme les JPEGs, les MP4s ou les exécutables compilés) sont souvent déjà compressés. Lorsque seules de petites modifications sont apportées à ces fichiers, Git a du mal à générer des deltas significatifs, ce qui entraîne souvent le stockage de copies presque complètes du fichier dans l'historique pour chaque révision. Cela accélère rapidement la croissance de la taille du dépôt.
Transfert d'historique Obligatoire : Le clonage d'un dépôt nécessite le téléchargement de l'historique complet. Si un projet contient un fichier de texture de 100 Mo qui a été modifié 50 fois, le clonage initial doit transférer plusieurs gigaoctets rien que pour l'historique de cet unique actif. Cela a un impact sévère sur la vélocité de développement, en particulier pour les nouveaux contributeurs ou les systèmes CI/CD.

Résultat : Les dépôts deviennent massifs, augmentant les temps de clonage, ralentissant les tâches de maintenance en arrière-plan (comme la collecte des déchets) et nécessitant un espace disque local excessif.

Présentation de Git Large File Storage (LFS)

Git LFS est une extension open source développée par GitHub (maintenant largement adoptée) qui modifie la manière dont Git gère les types de fichiers spécifiés. LFS déplace la charge de stockage du dépôt Git principal, préservant l'efficacité de Git pour le code source tout en externalisant les gros fichiers binaires.

Le système de pointeurs

Lorsqu'un fichier est suivi par LFS, le contenu binaire réel n'est pas stocké dans la base de données d'objets Git. Au lieu de cela, LFS stocke un petit fichier pointeur de texte standardisé dans le dépôt Git. Ce pointeur fait référence à l'emplacement du contenu binaire réel, lequel est stocké sur un serveur LFS dédié (généralement hébergé en parallèle du dépôt Git distant, par exemple GitHub, GitLab, Bitbucket).

Un fichier pointeur LFS ressemble à ceci :

version https://git-lfs.github.com/spec/v1
oid sha256:4c2d44962ff3c43734e56598c199589d8995a643...a89c89
size 104857600

L'avantage de performance : Récupération juste-à-temps (Just-in-Time)

L'avantage fondamental de performance de LFS est que, lors d'opérations comme le clonage ou le 'fetching', Git ne récupère que les petits pointeurs de texte. Les gros fichiers binaires réels ne sont téléchargés que lorsqu'ils sont explicitement nécessaires, généralement pendant une opération de 'checkout' (git checkout ou git lfs pull).

Comparaison des performances : LFS vs. Git Standard

Le tableau suivant résume les différences de performance pour les opérations de développement critiques lors de la gestion de gros actifs :

Opération	Performance Git Standard	Performance Git LFS	Avantage	Justification
Clonage Initial	Mauvaise/Très Lent	Excellente/Rapide	LFS	Seuls les petits pointeurs sont téléchargés ; les fichiers binaires sont récupérés à la demande.
Taille du Dépôt	Très Grande (Engorgé)	Petite (Mince)	LFS	Les fichiers binaires sont externalisés du répertoire `.git`.
Checkout/Changement de branche	Lent/I/O Élevé	Rapide	LFS	Récupère uniquement la version binaire spécifique requise via HTTP.
Temps de Build CI/CD	Lent (dû au clonage massif)	Rapide	LFS	Réduction significative du temps passé à cloner et à récupérer les dépendances.
Revue de l'Historique	Nécessite le téléchargement de l'historique complet	Pointeur uniquement (rapide)	LFS	L'historique reste léger et gérable.

1. Engorgement du dépôt et maintenance

Les dépôts Git standards sont notoirement difficiles à nettoyer une fois que de gros actifs y ont été commis, même si ces actifs sont supprimés ultérieurement (ils restent dans l'historique). Cela nécessite des outils complexes comme git filter-branch ou git filter-repo pour réécrire l'historique de manière permanente — un processus destructeur et chronophage.

Impact de LFS : Parce que LFS externalise les gros fichiers, la taille du dépôt Git principal reste uniformément petite et facile à gérer, réduisant drastiquement le temps nécessaire aux processus Git internes comme la collecte des déchets (git gc).

2. Bande passante et latence réseau

Pour les équipes distribuées, la bande passante réseau est une préoccupation majeure.

Git Standard : Chaque utilisateur doit tirer l'historique complet du dépôt, consommant des quantités massives de bande passante pour chaque nouveau clonage, quels que soient les fichiers dont il a réellement besoin.
Git LFS : LFS ne transfère que les blobs binaires spécifiques associés au commit actuellement extrait (checked-out). Si un utilisateur travaille uniquement sur la dernière branche de version, il ne télécharge que les fichiers binaires requis pour cette version spécifique, économisant ainsi une bande passante significative et accélérant le processus, en particulier sur les connexions plus lentes.

3. Charge du serveur

Gérer des dépôts massifs impose une charge élevée au serveur Git, en particulier lors d'opérations profondes comme le 'fetching' ou le 'pushing' de grands volumes de données. En déplaçant le mécanisme de stockage des gros fichiers vers un serveur LFS séparé et optimisé (qui utilise souvent des protocoles de stockage d'objets simples de type HTTP ou S3), le serveur Git principal reste performant pour les opérations standard de code source.

Quand utiliser Git LFS

Git LFS est le choix optimal pour tout fichier qui répond aux critères suivants :

Grande Taille : Généralement, les fichiers de plus de 500 Ko à 1 Mo.
Format Binaire : Fichiers qui ne se compressent pas bien (par exemple, images compressées, vidéo, audio).
Modifications Fréquentes : Fichiers qui sont mis à jour souvent, générant des versions répétées dans l'historique (par exemple, actifs de jeu en développement).

Candidats courants pour le suivi LFS :

*.psd, *.tiff, *.blend, *.max (Actifs de conception/3D)
*.mp4, *.mov, *.wav (Fichiers multimédias)
*.dll, *.exe, *.jar (Binaires compilés, s'ils sont commis)
Grands *.csv, *.parquet, ou instantanés de base de données (Science des données)

Mise en œuvre de Git LFS

La mise en œuvre de LFS est simple et nécessite l'installation du client LFS et la spécification des modèles de fichiers qui doivent être suivis.

Étape 1 : Installer et initialiser LFS

Tout d'abord, assurez-vous que le client Git LFS est installé sur votre machine. Ensuite, exécutez la commande d'installation une seule fois à l'intérieur de votre dépôt :

git lfs install

Étape 2 : Suivre les types de fichiers

Utilisez git lfs track pour indiquer à Git quels modèles de fichiers gérer via LFS. Cette commande crée ou met à jour le fichier .gitattributes, qui est crucial pour le bon fonctionnement de LFS.

Exemple : Suivi de tous les fichiers Photoshop et des gros fichiers vidéo

git lfs track "*.psd"
git lfs track "assets/*.mp4"

# Examiner les modifications apportées à .gitattributes
cat .gitattributes
# Exemple de sortie :
# *.psd filter=lfs diff=lfs merge=lfs -text
# assets/*.mp4 filter=lfs diff=lfs merge=lfs -text

Étape 3 : Commiter et Pusher

Il est crucial que vous committiez le fichier .gitattributes en même temps que les fichiers suivis. Lorsque vous 'pushez', Git transférera les pointeurs, et le client LFS se chargera de télécharger les gros fichiers binaires vers le stockage LFS.

git add .gitattributes assets/
git commit -m "Added LFS tracked PSDs and MP4s"
git push

⚠️ Bonne Pratique : Commiter .gitattributes en Premier

Le fichier .gitattributes doit être commis avant ou en même temps que les gros fichiers qu'il suit. Si vous commitez les gros fichiers en premier, Git les suivra nativement, ce qui annulera l'intérêt de LFS.

Conclusion

Git standard est imbattable pour son objectif initial : le contrôle de version du code source et des petits fichiers de configuration. Cependant, lorsque de gros actifs binaires sont introduits, ses performances se dégradent rapidement en raison de l'engorgement du dépôt et des transferts historiques obligatoires.

Git LFS offre une optimisation de performance cruciale en faisant abstraction du stockage des gros fichiers, garantissant que le dépôt Git principal reste léger, rapide à cloner et facile à maintenir. En utilisant le système de pointeurs et la récupération juste-à-temps, LFS transforme des opérations auparavant lentes en processus rapides, ce qui en fait un outil essentiel pour le développement de jeux, la science des données et tout projet traitant d'actifs binaires substantiels et fréquemment mis à jour.