Git LFS vs. Git Standard : Performances pour les Fichiers Lourds
Comparez Git LFS avec Git standard pour les fichiers lourds, y compris le comportement de clonage, les fichiers pointeurs, le suivi LFS et les cas où LFS est utile.
Git LFS vs. Git Standard : Performances pour les Fichiers Lourds
Git LFS vs. Git standard devient une vraie question lorsque votre dépôt commence à contenir des fichiers binaires lourds. Le code source se compresse et se différencie généralement bien, mais les vidéos, les fichiers de conception, les textures de jeux, les fichiers de modèles et les grands ensembles de données peuvent ralentir les clonages et rendre l'historique difficile à nettoyer.
Git Large File Storage, généralement appelé Git LFS, allège le dépôt Git normal en remplaçant certains fichiers par de petits fichiers pointeurs et en stockant le contenu réel dans un magasin d'objets LFS. Ce compromis aide de nombreuses équipes, mais ce n'est pas magique. Vous devez toujours choisir les bons fichiers, valider les règles de suivi et comprendre quand LFS télécharge le contenu.
Le Goulot d'Étranglement des Performances de Git Standard
Git standard stocke le contenu validé dans sa base de données d'objets et conserve suffisamment d'historique pour reconstruire chaque version validée. Cela fonctionne parfaitement pour les fichiers texte. Cela fonctionne mal lorsque le même fichier binaire de 200 Mo change plusieurs fois.
Deux problèmes apparaissent rapidement :
- Les formats binaires tels que JPEG, MP4, ZIP, PSD et les artefacts compilés ne se compressent souvent pas bien par delta.
- Les fichiers supprimés restent dans l'historique à moins que vous ne réécriviez l'historique.
- Les nouveaux clonages paient pour les erreurs passées car l'historique Git contient toujours ces anciens objets.
- Les commandes de maintenance du dépôt ont plus de données à inspecter et à empaqueter.
Par exemple, si une équipe valide un fichier de conception exporté volumineux à chaque sprint, supprimer le fichier de la branche actuelle plus tard ne supprime pas ses versions antérieures de l'historique. Les nouveaux développeurs et les tâches CI peuvent encore télécharger des données que personne n'utilise activement.
Présentation de Git Large File Storage (LFS)
Git LFS est une extension qui gère certains fichiers en dehors de la base de données d'objets Git normale. Votre dépôt conserve un petit pointeur texte. Le contenu réel du fichier réside dans le stockage LFS fourni par votre hébergeur Git ou un autre serveur LFS.
Le Système de Pointeurs
Un pointeur LFS ressemble à ceci :
version https://git-lfs.github.com/spec/v1
oid sha256:4c2d44962ff3c43734e56598c199589d8995a643...a89c89
taille 104857600
C'est ce pointeur que Git normal voit. Le client Git LFS télécharge le contenu réel du fichier lorsque l'extraction ou une commande LFS explicite en a besoin.
Comparaison des Performances : LFS vs. Git Standard
| Opération | Git Standard | Git LFS |
|---|---|---|
| Clone initial | Télécharge l'historique Git qui inclut les objets volumineux validés | Télécharge l'historique Git avec les fichiers pointeurs ; le contenu LFS peut être téléchargé lors de l'extraction selon la configuration |
| Croissance du dépôt | Les fichiers binaires volumineux peuvent gonfler l'historique .git |
L'historique Git reste plus petit car le contenu des fichiers suivis est externe |
| Extraction | Utilise les objets déjà dans la base de données Git | Peut nécessiter de récupérer les objets LFS pour la validation extraite |
| Tâches CI | Peut perdre du temps à télécharger des ressources historiques | Peut ignorer ou limiter les téléchargements LFS lorsque les builds n'ont pas besoin de ressources |
| Nettoyage | Nécessite une réécriture de l'historique pour supprimer les blobs validés anciens | Nécessite toujours de l'attention, mais les nouvelles versions suivies par LFS ne gonflent pas l'historique Git normal |
Le détail important est le comportement de l'extraction. Un simple git clone avec Git LFS installé télécharge souvent les fichiers LFS nécessaires pour la validation extraite. Si vous voulez uniquement les pointeurs, utilisez GIT_LFS_SKIP_SMUDGE=1 lors du clonage et récupérez les fichiers plus tard avec git lfs pull.
Quand Utiliser Git LFS
Git LFS est adapté aux fichiers volumineux, binaires et susceptibles de changer. Les exemples courants incluent :
*.psd,*.tiff,*.blendet autres ressources de conception ou 3D.*.mp4,*.mov,*.wavet autres fichiers multimédias.- Les fichiers de modèles volumineux, les fixtures de test ou les ensembles de données requis par le projet.
- Les binaires compilés uniquement lorsque le projet a une raison claire de les versionner.
Ne mettez pas tous les fichiers dans LFS simplement parce que vous le pouvez. Les fichiers texte, le code source, les petits fichiers de configuration et les fichiers que vous voulez que Git différencie normalement doivent rester dans Git standard.
Vérifiez les limites de stockage et de bande passante de votre fournisseur d'hébergement avant d'adopter LFS. GitHub, GitLab, Bitbucket et les plateformes auto-hébergées peuvent différer en termes de quotas, de facturation et de comportement de conservation.
Implémentation de Git LFS
Installez le client Git LFS, puis activez ses hooks pour votre utilisateur :
git lfs install
Suivez les motifs que vous voulez que LFS gère :
git lfs track "*.psd"
git lfs track "assets/*.mp4"
Ces commandes créent ou mettent à jour .gitattributes. Validez ce fichier avec les ressources qu'il affecte :
git add .gitattributes assets/
git commit -m "Suivre les ressources de conception avec Git LFS"
git push
Si un fichier volumineux a déjà été validé dans l'historique Git normal, le suivre avec LFS n'affecte que les futures validations. Pour migrer l'historique existant, utilisez un outil de migration tel que git lfs migrate import, et coordonnez-vous soigneusement car la réécriture de l'historique modifie les identifiants de validation.
Pour cloner sans télécharger immédiatement le contenu LFS, utilisez :
GIT_LFS_SKIP_SMUDGE=1 git clone [email protected]:example/assets-heavy-repo.git
cd assets-heavy-repo
git lfs pull --include="assets/*.mp4"
Conclusion Pratique
Utilisez Git standard pour le code source et les petits fichiers texte. Utilisez Git LFS pour les fichiers binaires volumineux qui appartiennent au dépôt mais ne doivent pas gonfler l'historique Git normal.
Pour un dépôt d'équipe, ajoutez les règles LFS tôt, validez .gitattributes, documentez comment CI gère les téléchargements LFS et vérifiez les limites LFS de votre hôte. Cela vous donne l'avantage en termes de performances sans surprendre les développeurs lors du clonage, de l'extraction ou des builds de version.