Git lfs

Git est devenu le système de contrôle de version de facto pour les développeurs de logiciels du monde entier. Ce système de contrôle de version distribué open source est plus rapide que ses concurrents. Il est facile à utiliser pour la branche et la fusion du code. Cependant, il a un problème de performances avec de grands fichiers binaires. Le stockage de fichiers Git Large (LFS) a été développé pour résoudre ce problème.

Le problème de fichier gros dans GIT

Traditionnellement, certaines entreprises et institutions sont restées à l'écart du GIT en raison de l'inefficacité de la manipulation des fichiers binaires importants. Les développeurs de jeux vidéo et les sociétés de médias doivent faire face à des textures complexes, des vidéos en mouvement complet et des fichiers audio de haute qualité. Les instituts de recherche doivent garder une trace de grands ensembles de données qui peuvent être des gigaoctets ou des téraoctets. Git a du mal à maintenir ces grands fichiers.

Pour comprendre le problème, nous devons voir comment Git garde la trace des fichiers. Chaque fois qu'il y a un engagement, Git crée un nœud d'objet avec un pointeur vers son parent ou plusieurs parents. Le modèle de données GIT est connu sous le nom de graphique acyclique dirigé (DAG). Le modèle DAG garantit que la relation parent-enfant ne peut jamais former de cycles.

Nous pouvons inspecter le fonctionnement interne du modèle DAG. Voici un exemple de trois commits dans un référentiel:

$ Git Log --Oneline
2BEB263 Commit C: Image ajouté1.jpeg
866178E Commit B: Ajouter B.SMS
D48dd8b Commit A: Ajouter un.SMS

Dans Commit A et B, nous avons ajouté le fichier texte A.txt et b.SMS. Ensuite, dans Commit C, nous avons ajouté un fichier image appelé Image1.jpeg. Nous pouvons visualiser le DAG comme suit:

Commit c commettre b commettre un
2BEB263 -> 866178E -> d48dd8b

Si nous inspectons le dernier engagement avec la commande suivante:

$ git cat-file -p 2beb263
arbre 7cc17ba5b041fb227b9ab5534d81bd836183a4e3
parent 866178e37df64d9f19fa77c00d5ba9d3d4fc68f5
Auteur Zak H 1513259427 -0800
Committe Zak H 1513259427 -0800
Commit C: Ajout de l'image1.jpeg

Nous pouvons voir que Commit C (2BEB263) a commet B (866178E) en tant que parent. Maintenant, si nous inspectons l'objet d'arbre de Commit C (7cc17ba), nous pouvons voir les blobs (grands objets binaires):

$ git cat-file -p 7cc17ba
100644 BLOB E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 A.SMS
100644 BLOB E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 B.SMS
100644 BLOB A44A66F9E06A8FAF324D3FF3E11C9FA6966BFB56 Image1.jpeg

Nous pouvons vérifier la taille du blob d'image:

$ git cat-file -s a44a66f9e
871680

Git garde une trace des changements dans cette structure d'arbre. Faisons une modification de l'image1.jpeg et vérifiez l'histoire:

$ Git Log --Oneline
2E257DB Commit D: Image modifiée1.jpeg
2BEB263 Commit C: Image ajouté1.jpeg
866178E Commit B: Ajouter B.SMS
D48dd8b Commit A: Ajouter un.SMS

Si nous vérifions l'objet Commit D (2E257DB):

$ git cat-file -p 2e257db
arbre 2405fad67610acf0f57b87af36f535c1f4f9ed0d
Parent 2BeB263523725E1E8F9D96083140A4A5CD30B651
Auteur Zak H 1513272250 -0800
Committe Zak H 1513272250 -0800
Commit D: Image modifié1.jpeg

Et l'arbre (2405fad) à l'intérieur:

$ git cat-file -p 2405fad
100644 BLOB E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 A.SMS
100644 BLOB E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 B.SMS
100644 BLOB CB4A0B67280A92412A81C60DF36A15150E713095 Image1.jpeg

Remarquez que le hachage SHA-1 pour Image1.jpeg a changé. Cela signifie qu'il a créé un nouveau blob pour Image1.jpeg. Nous pouvons vérifier la taille du nouveau blob:

$ git cat-file -s cb4a0b6
1063696

Voici un moyen de visualiser la structure DAG ci-dessus:

Engager d commet c commit b commit a
| | | |
2E257DB -> 2BEB263 -> 866178E -> D48DD8B
| | | |
Arbre4 arbre3 arbre2 arbre1
| | | |
Blobs blobs blobs blobs
[/ cce_c]
Chaque objet de validation maintient son propre arbre. Des taches sont maintenues à l'intérieur de cet arbre. Git optimise l'espace en s'assurant qu'il stocke uniquement les différences et utilise la compression du stockage. Mais pour les modifications de fichiers binaires, Git doit stocker des fichiers entiers dans les blobs car il est difficile de déterminer les différences. De plus, les fichiers d'image, de vidéo et d'audio sont déjà compressés. En conséquence, pour chaque instance d'un fichier binaire modifié, l'arbre se retrouve avec un grand blob.
Pensons à un exemple où nous apportons plusieurs modifications dans un fichier image de 100 Mo.
[cc width = "100%" height = "100%" échappé = "true" thème = "Blackboard" Nowrap = "0"]
Commettre c -> commiser b -> commettre un
| | |
Arbre3 arbre2 arbre1
| | |
BLOB3 BLOB2 BLOB1
300 Mb 200 Mo 100 Mo
[/ cce_c]
Chaque fois que nous modifions le fichier, Git doit créer un blob de 100 Mo. Donc seulement après 3 commits, le référentiel Git est de 300 Mo. Vous pouvez voir que la taille du référentiel Git peut rapidement exploser. Parce que Git est un contrôle de version distribuée, vous allez télécharger l'intégralité du référentiel sur votre instance locale et travailler beaucoup avec les succursales. Les grands blobs deviennent donc un goulot d'étranglement des performances.
Le GIT LFS résout le problème en remplaçant les blobs par des fichiers de pointeurs légers (PF) et en créant un mécanisme pour stocker les blobs ailleurs.
[cc width = "100%" height = "100%" échappé = "true" thème = "Blackboard" Nowrap = "0"]
Commettre c -> commiser b -> commettre un
| | |
Arbre3 arbre2 arbre1
| | |
PF3 PF2 PF1
[/ cce_c]
Localement, Git stocke les blobs dans le cache Git LFS, et à distance, il les stockera dans le magasin Git LFS sur GitHub ou Bitbucket.
[cc width = "100%" height = "100%" échappé = "true" thème = "Blackboard" Nowrap = "0"]
PF1 -> BLOB1
PF2 -> BLOB2
PF3 -> BLOB3
[/ cce_bash]
Maintenant, lorsque vous traitez avec le référentiel GIT, les fichiers PF légers seront utilisés pour les opérations de routine. Les blobs ne seront récupérés que si nécessaire. Par exemple, si vous cochez COMMISS. Le référentiel de travail sera donc plus maigre et les performances seront meilleures. Vous n'avez pas à vous soucier des fichiers du pointeur. Git LFS les gérera dans les coulisses.

Installation et exécution de Git LFS

Il y a eu une tentative antérieure pour résoudre le problème du fichier Git Git. Mais Git LFS a réussi parce qu'il est facile à utiliser. Il vous suffit d'installer LFS et de lui dire quels fichiers suivent.
Vous pouvez installer Git LFS en utilisant les commandes suivantes:
[cc width = "100%" height = "100%" échappé = "true" thème = "Blackboard" Nowrap = "0"]
$ sudo apt-get install logiciel-properties-commun
$ curl -s https: // packageCloud.io / install / repositories / github / git-lfs / script.deb.sh | Sudo Bash
$ sudo apt-get install git-lfs
$ git lfs install

Une fois que vous avez installé Git LFS, vous pouvez suivre les fichiers souhaités:

$ git lfs piste "*.JPEG "
Suivi "*.JPEG "

La sortie vous montre que Git LFS suit les fichiers JPEG. Lorsque vous commencez à suivre avec LFS, vous trouverez un .Fichier Gitattributes qui aura une entrée affichant les fichiers suivis. Le .gitattributes fichier utilisez la même notation que .fichier gitignore. Voici comment le contenu de .Gitattributes looks:

$ chat .gitattributes
*.JPEG Filter = LFS Diff = LFS Merge = LFS -Text

Vous pouvez également trouver quels fichiers sont suivis à l'aide de la commande suivante:

$ git lfs piste
Listing des modèles suivis
*.JPEG (.gitattributes)

Si vous souhaitez arrêter de suivre un fichier, vous pouvez utiliser la commande suivante:

$ git lfs unmul "*.JPEG "
Non-retrouvant "*.JPEG "

Pour les opérations du général Git, vous n'avez pas à vous soucier de la LFS. Il s'occupera automatiquement de toutes les tâches backend. Une fois que vous avez configuré Git LFS, vous pouvez travailler sur le référentiel comme n'importe quel autre projet.

---

Une étude plus approfondie

Pour des sujets plus avancés, examinez les ressources suivantes:

• Déplacement du référentiel GIT LFS entre les hôtes
• Suppression de fichiers Git LFS locaux
• Suppression des fichiers Git LFS distants du serveur
• Site Web Git LFS
• Documentation GIT LFS

Les références:

• git-lfs.github.com: repo github
• github.com / git-lfs / git-lfs / arbre / maître / docs: documentation github pour git lfs
• atlassien.com / git / tutoriels / git-lfs: tutoriels atlassiens
• Youtube.com: Qu'est-ce que Git LFS
• Youtube.com: suivi d'énormes fichiers avec Git LFS par Tim Pettersen, Atlassian
• Youtube.com: Gérer d'énormes fichiers sur le bon stockage avec Git LFS, YouTube
• Youtube.com: Git Large File Storage - Comment travailler avec de gros fichiers, YouTube
• github.com / git-lfs / git-lfs / blob / maître / installation.MD: Guide d'installation