Stockage de fichiers volumineux Git (LFS)

Stockage de fichiers volumineux Git (LFS)

Qu'est-ce que Git LFS ?

Git est un système de contrôle de version distribué, autrement dit, l'historique entier du dépôt est transféré au client durant le processus de clonage. Pour les projets contenant des fichiers volumineux, en particulier des fichiers volumineux qui sont régulièrement modifiés, ce clonage initial peut prendre énormément de temps, car chaque version de chaque fichier doit être téléchargée par le client. Git LFS (Large File Storage) est une extension de Git développée par Atlassian, GitHub, et quelques autres contributeurs open source, qui réduit l'impact des fichiers volumineux dans votre dépôt en téléchargeant paresseusement les versions de ces fichiers. Plus précisément, les fichiers volumineux sont téléchargés au cours du processus d'extraction plutôt que pendant le clonage ou la récupération.

Pour cela, Git LFS remplace les fichiers volumineux dans votre dépôt par de petits fichiers de pointeur. Lors d'une utilisation normale, vous ne verrez jamais ces fichiers de pointeur, car ils sont automatiquement gérés par Git LFS :

  1. Lorsque vous ajoutez un fichier à votre dépôt, Git LFS remplace son contenu par un pointeur, puis stocke le contenu du fichier dans un cache Git LFS local. 

    git lfs - git add
  2. Lorsque vous pushez de nouveaux commits vers le serveur, tous les fichiers Git LFS référencés par les commits récemment pushés sont transférés de votre cache Git LFS local vers le magasin Git LFS distant lié à votre dépôt Git. 

    git lfs - git push
  3. Lorsque vous extrayez un commit contenant des pointeurs Git LFS, ces pointeurs sont remplacés par des fichiers de votre cache Git LFS local, ou téléchargés depuis le magasin Git LFS distant. git lfs - git checkout

Git LFS est transparent : dans votre copie de travail, vous verrez uniquement le contenu de votre fichier actuel. Autrement dit, vous pouvez utiliser Git LFS sans changer votre workflow Git existant ; exécutez simplement les opérations git checkout, edit, git add et git commit comme d'habitude. Les opérations git clone et git pull seront significativement plus rapides, car vous ne téléchargez que les versions des fichiers volumineux référencés par des commits que vous avez véritablement extraits, et non toutes les versions passées du fichier.

Pour utiliser Git LFS, vous aurez besoin d'un hôte compatible Git LFS, comme Bitbucket Cloud ou Bitbucket Server. Les utilisateurs de dépôt auront besoin du client de ligne de commande Git LFS ou d'un client d'interface graphique compatible Git LFS, comme Sourcetree. Anecdote : Steve Streeting, le développeur Atlassian qui a inventé Sourcetree, contribue également activement au projet Git LFS. C'est pourquoi Sourcetree et Git LFS fonctionnent plutôt bien ensemble.

Qu'est-ce que Git LFS ?

Installation de Git LFS

  1. Il existe trois façons d'installer facilement Git LFS :

    a. Installez-le avec votre gestionnaire de package favori. Les packages git-lfs sont disponibles pour Homebrew, MacPorts, dnf et packagecloud ; ou

    b. Télécharger et installer Git LFS à partir du site Web du projet ; ou

    c. Installez Sourcetree, un client d'interface graphique gratuit livré avec Git LFS.

  2. Une fois que git-lfs est sur installé, exécutez git lfs install pour initialiser Git LFS (vous pouvez passer cette étape si vous avez installé Sourcetree) :

    $ git lfs install
    Git LFS initialized.
    

    Vous ne devez exécuter git lfs install qu'une fois. Une fois initialisé pour votre système, Git LFS effectue automatiquement un bootstrap lorsque vous clonez un dépôt avec du contenu Gif LFS.

Création d'un nouveau dépôt Git LFS

Pour créer un nouveau dépôt aware Git LFS, vous devez exécuter git lfs install après avoir créé le dépôt :

# Initialisez Git
$ mkdir Atlasteroids
$ cd Atlasteroids
$ git init
Initialized empty Git repository in /Users/tpettersen/Atlasteroids/.git/
# Initialisez Git LFS
$ git lfs install
Updated pre-push hook.
Git LFS initialized.

Cela installe un hook Git pre-push dans votre dépôt qui transfère les fichiers Git LFS vers votre serveur lors de l'exécution de git push.

Git LFS est automatiquement activé pour tous les dépôts Bitbucket Cloud. Pour Bitbucket Server, vous devrez activer Git LFS dans les paramètres de votre dépôt :

Git LFS dans Bitbucket Server

Une fois Git LFS initialisé pour votre dépôt, vous pouvez spécifier les fichiers à suivre avec git lfs track.

Clonage d'un dépôt Git LFS existant

Une fois Git LFS installé, vous pouvez cloner un dépôt Git LFS normalement avec git clone. Au terme du processus de clonage, Git extrait la branche par défaut (généralement, la branche master), et tous les fichiers Git LFS requis pour le processus d'extraction sont automatiquement téléchargés pour vous. Par exemple :

$ git clone git@bitbucket.org:tpettersen/Atlasteroids.git
Cloning into 'Atlasteroids'...
remote: Counting objects: 156, done.
remote: Compressing objects: 100% (154/154), done.
remote: Total 156 (delta 87), reused 0 (delta 0)
Receiving objects: 100% (156/156), 54.04 KiB | 31.00 KiB/s, done.
Resolving deltas: 100% (87/87), done.
Checking connectivity... done.
Downloading Assets/Sprites/projectiles-spritesheet.png (21.14 KB)
Downloading Assets/Sprites/productlogos_cmyk-spritesheet.png (301.96 KB)
Downloading Assets/Sprites/shuttle2.png (1.62 KB)
Downloading Assets/Sprites/space1.png (1.11 MB)
Checking out files: 100% (81/81), done.

Ce dépôt contient quatre PNG suivis par Git LFS. Lors de l'exécution de git clone, les fichiers Git LFS sont téléchargés individuellement lorsque les fichiers de pointeur sont extraits de votre dépôt.

Accélération des clones

Si vous clonez un dépôt contenant de nombreux fichiers LFS, la commande explicite git lfs clone assure de bien meilleures performances :

$ git lfs clone git@bitbucket.org:tpettersen/Atlasteroids.git
Cloning into 'Atlasteroids'...
remote: Counting objects: 156, done.
remote: Compressing objects: 100% (154/154), done.
remote: Total 156 (delta 87), reused 0 (delta 0)
Receiving objects: 100% (156/156), 54.04 KiB | 0 bytes/s, done.
Resolving deltas: 100% (87/87), done.
Checking connectivity... done.
Git LFS: (4 of 4 files) 1.14 MB / 1.15 MB

Au lieu de télécharger les fichiers Git LFS en une fois, la commande git lfs clone attend la fin de l'extraction, puis télécharge tous les fichiers Git LFS requis en lot. Cela tire parti des téléchargements parallélisés et réduit considérablement le nombre de requêtes HTTP et de processus engendrés (ce qui est particulièrement important pour améliorer les performances sous Windows).

Pulls et extractions

À l'instar du clonage, vous pouvez faire un pull à partir d'un dépôt Git LFS avec une commande git pull. Tous les fichiers Git LFS nécessaires seront téléchargés dans le cadre du processus de checkout automatique une fois le pull effectué :

$ git pull
Updating 4784e9d..7039f0a
Downloading Assets/Sprites/powerup.png (21.14 KB)
Fast-forward
Assets/Sprites/powerup.png | 3 +
Assets/Sprites/powerup.png.meta | 4133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 4136 insertions(+)
create mode 100644 Assets/Sprites/projectiles-spritesheet.png
create mode 100644 Assets/Sprites/projectiles-spritesheet.png.meta

Aucune commande explicite n'est requise pour récupérer le contenu Git LFS. Cependant, si la commande échoue pour une raison inattendue, vous pouvez télécharger tout le contenu Git LFS manquant pour le commit actuel avec git lfs pull :

$ git lfs pull
Git LFS: (4 of 4 files) 1.14 MB / 1.15 MB

Accélération des pulls

À l'instar de git lfs clone, git lfs pull télécharge vos fichiers Git LFS en lot. Si vous savez qu'un grand nombre de fichiers ont été modifiés depuis votre dernier pull, vous souhaitez peut-être désactiver le téléchargement automatique Git LFS pendant l'extraction, puis télécharger en lot votre contenu Git LFS avec une commande git lfs pull explicite. Pour cela, remplacez votre configuration Git par l'option -c lorsque vous appelez git pull :

$ git -c filter.lfs.smudge= -c filter.lfs.required=false pull && git lfs pull

Puisqu'il y a beaucoup à saisir, vous souhaitez peut-être créer un simple alias Git pour réaliser un pull Git et Git LFS en lot pour vous :

$ git config --global alias.plfs "\!git -c filter.lfs.smudge= -c filter.lfs.required=false pull && git lfs pull"
$ git plfs

Cela améliorera grandement les performances lorsqu'un grand nombre de fichiers Git LFS doivent être téléchargés (à nouveau, surtout sous Windows).

Suivi de fichiers avec Git LFS

Lorsque vous ajoutez un nouveau type de fichier volumineux à votre dépôt, vous devez indiquer à Git LFS de le suivre en spécifiant un modèle à l'aide de la commande git lfs track :

$ git lfs track "*.ogg"
Tracking *.ogg

Notez que les guillemets autour de "*.ogg" sont importants. Les omettre étendra le caractère générique à votre invite shell, et des entrées individuelles seront créées pour chaque fichier .ogg dans votre répertoire actuel :

# Ce n'est probablement pas ce que vous souhaitez
$ git lfs track *.ogg
Tracking explode.ogg
Tracking music.ogg
Tracking phaser.ogg

Les modèles pris en charge par Git LFS sont les mêmes que ceux pris en charge par .gitignore, par exemple :

# Trackez tous les fichiers .ogg dans tous les répertoires
$ git lfs track "*.ogg"
# Trackez les fichiers intitulés music.ogg dans tous les répertoires
$ git lfs track "music.ogg"
# Trackez tous les fichiers dans le répertoire Assets et dans tous les sous-répertoires
$ git lfs track "Assets/"
# Trackez tous les fichiers dans le répertoire Assets mais *pas* les sous-répertoires
$ git lfs track "Assets/*"
# Trackez tous les fichiers ogg dans Assets/Audio
$ git lfs track "Assets/Audio/*.ogg"
# Trackez tous les fichiers ogg dans tous les répertoires intitulés Music
$ git lfs track "**/Music/*.ogg"
# Trackez les fichiers png contenant "xxhdpi" dans leur nom, quel que soit leur répertoire
$ git lfs track "*xxhdpi*.png

Ces modèles dépendent du répertoire dans lequel vous exécutez la commande git lfs track. Pour faire simple, il vaut mieux exécuter git lfs track à la source de votre dépôt. Notez que Git LFS ne prend pas en charge les modèles négatifs comme .gitignore.

Après avoir exécuté git lfs track, vous remarquerez un nouveau fichier appelé .gitattributes dans le répertoire à partir duquel vous avez exécuté la commande. .gitattributes est un mécanisme Git qui permet de lier des comportements spéciaux à certains modèles de fichiers. Git LFS crée ou met à jour automatiquement les fichiers .gitattributes pour lier les modèles de fichiers trackés au filtre Git LFS. Toutefois, vous devrez commiter vous-même tous les changements apportés au fichier .gitattributes vers votre dépôt :

$ git lfs track "*.ogg"
Tracking *.ogg
$ git add .gitattributes
$ git diff --cached
diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..b6dd0bb
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+*.ogg filter=lfs diff=lfs merge=lfs -text
$ git commit -m "Track ogg files with Git LFS"

Pour faciliter la maintenance, il est plus simple de conserver tous les modèles Git LFS dans un fichier .gitattributes unique en exécutant toujours git lfs track depuis la racine de votre dépôt. Toutefois, vous pouvez afficher une liste de tous les modèles actuellement suivis par Git LFS (et des fichiers .gitattributes dans lesquels ils sont définis) en appelant git lfs track sans argument :

$ git lfs track
Listing tracked paths
*.stl (.gitattributes)
*.png (Assets/Sprites/.gitattributes)
*.ogg (Assets/Audio/.gitattributes)

Vous pouvez arrêter de suivre un modèle particulier avec Git LFS en retirant simplement la ligne appropriée de votre fichier .gitattributes, ou en exécutant la commande git lfs untrack :

$ git lfs untrack "*.ogg"
Untracking *.ogg
$ git diff
diff --git a/.gitattributes b/.gitattributes
index b6dd0bb..e69de29 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1 +0,0 @@
-*.ogg filter=lfs diff=lfs merge=lfs -text

Après avoir exécuté git lfs untrack, vous devrez à nouveau commiter vous-mêmes les changements vers .gitattributes.

Commits et pushes

Vous pouvez faire un commit et un push normalement vers un dépôt avec du contenu Git LFS. Si vous avez commité des changements vers des fichiers trackés par Git LFS, vous verrez des sorties supplémentaires depuis git push à mesure que le contenu Git LFS est transféré vers le serveur.

$ git push
Git LFS: (3 of 3 files) 4.68 MB / 4.68 MB
Counting objects: 8, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.16 KiB | 0 bytes/s, done.
Total 8 (delta 1), reused 0 (delta 0)
To git@bitbucket.org:tpettersen/atlasteroids.git
7039f0a..b3684d3 master -> master

Si le transfert des fichiers volumineux (LFS) échoue pour une quelconque raison, le push est annulé, et vous pouvez réessayer en toute sécurité. À l'instar de Git, le stockage Git LFS est adressable en contenu : le contenu est stocké avec une clé correspondant à une empreinte SHA-256 du contenu lui-même. Autrement dit, vous pouvez toujours réessayer sans risque de transférer des fichiers Git LFS vers le serveur ; vous ne pouvez pas remplacer accidentellement le contenu d'un fichier Git LFS par une mauvaise version.

Migration d'un dépôt Git LFS entre des hôtes

Pour migrer un dépôt Git LFS d'un fournisseur d'hébergement vers un autre, vous pouvez utiliser une combinaison de git lfs fetch et git lfs push, en spécifiant --all option.

Par exemple, pour migrer tous les dépôts Git et Git LFS depuis un dépôt distant nommé github vers un dépôt distant nommé bitbucket :

# Créez un clone bare du dépôt GitHub
$ git clone --bare git@github.com:kannonboy/atlasteroids.git
$ cd atlasteroids
# Configurez les dépôts distants nommés pour Bitbucket et GitHub
$ git remote add bitbucket git@bitbucket.org:tpettersen/atlasteroids.git
$ git remote add github git@github.com:kannonboy/atlasteroids.git
# Extrayez tout le contenu Git LFS de GitHub
$ git lfs fetch --all github
# Pushez tout le contenu Git et Git LFS vers Bitbucket
$ git push --mirror bitbucket
$ git lfs push --all bitbucket

Fetcher l'historique Git LFS supplémentaire

Git LFS ne télécharge normalement que les fichiers requis pour les commits que vous extrayez localement. Toutefois, vous pouvez forcer Git LFS à télécharger du contenu supplémentaire pour d'autres branches récemment modifiées avec git lfs fetch --recent :

$ git lfs fetch --recent
Fetching master
Git LFS: (0 of 0 files, 14 skipped) 0 B / 0 B, 2.83 MB skipped Fetching recent branches within 7 days
Fetching origin/power-ups
Git LFS: (8 of 8 files, 4 skipped) 408.42 KB / 408.42 KB, 2.81 MB skipped
Fetching origin/more-music
Git LFS: (1 of 1 files, 14 skipped) 1.68 MB / 1.68 MB, 2.83 MB skipped

Ceci est utile pour télécharger en lots du nouveau contenu Git LFS pendant votre pause déjeuner, ou si vous envisagez d'examiner le travail de vos coéquipiers et que vous ne pourrez pas télécharger du contenu plus tard en raison d'une connexion Internet limitée. Par exemple, vous souhaitez peut-être exécuter git lfs fetch --recent avant de prendre l'avion !

Git LFS considère les branches ou les tags contenant un commit antérieur à sept jours comme récents. Vous pouvez configurer le nombre de jours considérés comme récents en définissant la propriété lfs.fetchrecentrefsdays :

# Téléchargez le contenu Git LFS pour les branches ou les tags mis à jour au cours des 10 derniers jours
$ git config lfs.fetchrecentrefsdays 10

Par défaut, git lfs fetch --recent téléchargera uniquement le contenu Git LFS pour le commit à la pointe d'une branche ou d'un tag récent.

git lfs - git lfs fetch --recent

Toutefois, vous pouvez configurer Git LFS pour qu'il télécharge le contenu de commits antérieurs sur des branches et des tags récents en configurant la propriété lfs.fetchrecentcommitsdays :

# Téléchargez les trois derniers jours de contenu Git LFS pour chaque branche ou tag récent(e)
$ git config lfs.fetchrecentcommitsdays 3

Utilisez ce paramètre avec précaution : si vous disposez de branches évoluant rapidement, cela peut provoquer le téléchargement d'une immense quantité de données. Toutefois, cela peut être utile si vous devez passer en revue des changements interstitiels sur une branche, sélectionner des commits dans plusieurs branches ou réécrire l'historique.

git lfs - git lfs fetch --recent commits

Comme nous l'avons vu dans Migration d'un dépôt Git LFS entre des hôtes, vous pouvez également choisir d'extraire tout le contenu Git LFS de votre dépôt avec git lfs fetch --all:

$ git lfs fetch --all
Scanning for all objects ever referenced...
✔ 23 objects found
Fetching objects...
Git LFS: (9 of 9 files, 14 skipped) 2.06 MB / 2.08 MB, 2.83 MB skipped

Suppression des fichiers Git LFS locaux

Vous pouvez supprimer des fichiers de votre cache Git LFS local avec la commande git lfs prune :

$ git lfs prune
✔ 4 local objects, 33 retained
Pruning 4 files, (2.1 MB)
✔ Deleted 4 files

Cela supprimera tous les fichiers Git LFS locaux considérés comme anciens. Un fichier ancien est un fichier qui n'est pas référencé par :

  • le commit en cours d'extraction ;
  • un commit qui n'a pas encore été pushé (vers l'origine ou vers la valeur définie pour lfs.pruneremotetocheck)
  • un commit récent.

Par défaut, un commit récent est un commit créé au cours des dix derniers jours. Cela est calculé en ajoutant :

  • la valeur de la propriété lfs.fetchrecentrefsdays discutée dans Fetcher l'historique Git LFS supplémentaire (définie par défaut sur sept) ; et
  • la valeur de la propriété lfs.pruneoffsetdays (qui, par défaut est trois).
git lfs prune

Vous pouvez configurer la sortie de suppression pour conserver plus longtemps le contenu Git LFS :

# Ne supprimez pas les commits de moins de quatre semaines (7 + 21)
$ git config lfs.pruneoffsetdays 21

Contrairement au nettoyage de type garbage collection intégré à Git, le contenu Git LFS n'est pas supprimé automatiquement. Exécuter régulièrement git lfs prune est une bonne idée pour limiter la taille de votre dépôt local.

Vous pouvez tester l'effet d'une opération de suppression avec git lfs prune --dry-run :

$ git lfs prune --dry-run
✔ 4 local objects, 33 retained
4 files would be pruned (2.1 MB)

Et vous pouvez connaître exactement les objets Git LFS qui seront supprimés avec git lfs prune --verbose --dry-run :

$ git lfs prune --dry-run --verbose
✔ 4 local objects, 33 retained
4 files would be pruned (2.1 MB)
* 4a3a36141cdcbe2a17f7bcf1a161d3394cf435ac386d1bff70bd4dad6cd96c48 (2.0 MB)
* 67ad640e562b99219111ed8941cb56a275ef8d43e67a3dac0027b4acd5de4a3e (6.3 KB)
* 6f506528dbf04a97e84d90cc45840f4a8100389f570b67ac206ba802c5cb798f (1.7 MB)
* a1d7f7cdd6dba7307b2bac2bcfa0973244688361a48d2cebe3f3bc30babcf1ab (615.7 KB)

Les longues chaînes hexadécimales générées par le mode --verbose sont des empreintes SHA-256 (également connues comme ID d'objet ou OID) des objets Git LFS à supprimer. Vous pouvez utiliser les techniques décrites dans Recherche de chemins ou de commits faisant référence à un objet Git LFS pour en savoir plus sur les objets qui seront supprimés.

À titre de contrôle de sécurité supplémentaire, vous pouvez utiliser l'option --verify-remote pour déterminer si le magasin Git LFS distant dispose d'une copie de vos objets Git LFS avant qu'ils ne soient supprimés :

$ git lfs prune --verify-remote
✔ 16 local objects, 2 retained, 12 verified with remote
Pruning 14 files, (1.7 MB)
✔ Deleted 14 files

Le processus de suppression est considérablement ralenti, mais soyez tranquille, tous les objets supprimés sont récupérables depuis le serveur. Vous pouvez en permanence activer l'option --verify-remote pour votre système en configurant la propriété lfs.pruneverifyremotealways à l'échelle globale :

$ git config --global lfs.pruneverifyremotealways true

Vous pouvez également activer la vérification à distance uniquement pour le dépôt de contexte en omettant l'option --global de la commande ci-dessus.

Suppression de fichiers Git LFS distants depuis le serveur

Le client de ligne de commande Git LFS ne prend pas en charge la suppression de fichiers depuis le serveur, donc la façon de les effacer dépend de votre fournisseur d'hébergement.

Dans Bitbucket Cloud, vous pouvez afficher et supprimer les fichiers Git LFS via Paramètres de dépôt > Git LFS :

Bitbucket Cloud : supprimer LFS du serveur

Notez que chaque fichier Git LFS est indexé par son OID SHA-256. Les chemins qui référencent chaque fichier ne sont pas visibles via l'interface utilisateur. C'est parce qu'il peut exister de nombreux chemins différents pour de nombreux commits différents qui peuvent faire référence à un objet donné. Les rechercher serait donc un processus lent.

Pour déterminer ce qu'un fichier Git LFS contient réellement, vous avez trois possibilités :

  • Consulter l'image d'aperçu et le type du fichier dans la colonne de gauche de l'interface utilisateur Bitbucket Git LFS.
  • Téléchargez le fichier à l'aide du lien dans la colonne de droite de l'interface utilisateur Bitbucket Git LFS. Recherchez les commits qui référencent l'OID SHA-256 de l'objet, comme expliqué à la section suivante.

Recherche de chemins ou de commits faisant référence à un objet Git LFS

Si vous disposez d'un Git LFS SHA-256 OID, vous pouvez déterminer les commits qui y font référence avec git log --all -p -S <OID> :

$ git log --all -p -S 3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
commit 22a98faa153d08804a63a74a729d8846e6525cb0
Author: Tim Pettersen <tpettersen@atlassian.com>
Date: Wed Jul 27 11:03:27 2016 +1000
Projectiles and exploding asteroids
diff --git a/Assets/Sprites/projectiles-spritesheet.png
new file mode 100755
index 0000000..49d7baf
--- /dev/null
+++ b/Assets/Sprites/projectiles-spritesheet.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
+size 21647

Cet appel git log génère un patch (-p) à partir des commits sur chaque branche (--all) qui ajoutent ou retirent une ligne (-S) contenant la chaîne spécifiée (Git LFS SHA-256 OID).

Le patch vous montre le commit et le chemin vers l'objet LFS, et vous indique qui l'a ajouté et la date du commit. Vous pouvez simplement faire un checkout du commit : si nécessaire, Git LFS téléchargera le fichier et le placera dans votre copie de travail.

Si vous suspectez qu'un objet Git LFS spécifique se trouve dans votre HEAD actuel ou sur une branche spécifique, vous pouvez utiliser git grep pour rechercher le chemin d'accès au fichier qui le référence :

# Recherchez un objet donné par OID dans HEAD
$ git grep 3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc HEAD
HEAD:Assets/Sprites/projectiles-spritesheet.png:oid sha256:3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
# Recherchez un objet donné par OID dans la branche "power-ups"
$ git grep e88868213a5dc8533fc9031f558f2c0dc34d6936f380ff4ed12c2685040098d4 power-ups
power-ups:Assets/Sprites/shield2.png:oid sha256:e88868213a5dc8533fc9031f558f2c0dc34d6936f380ff4ed12c2685040098d4

Vous pouvez remplacer HEAD ou power-ups par toute réf, tout commit ou toute arborescence contenant l'objet Git LFS.

Inclusion/Exclusion de fichiers Git LFS

Dans certains cas, vous souhaiterez peut-être télécharger uniquement un sous-ensemble du contenu Git LFS disponible pour un commit spécifique. Par exemple, lorsque vous configurez un build de CI pour exécuter des tests unitaires, vous avez peut-être uniquement besoin de votre code source et souhaitez exclure les fichiers lourds qui ne sont pas nécessaires pour faire un build de votre code.

Vous pouvez exclure un modèle ou un sous-répertoire avec git lfs fetch -X (ou --exclude) :

$ git lfs fetch -X "Assets/**"

Vous souhaitez peut-être également inclure un modèle ou un sous-répertoire spécifique. Par exemple, un ingénieur du son récupère juste les fichiers ogg et wav avec git lfs fetch -I (ou --include) :

$ git lfs fetch -I "*.ogg,*.wav"

Si vous combinez « includes » et « excludes », seuls les fichiers qui correspondent à un modèle « include » et qui ne correspondent pas à un modèle « exclude » seront fetchés. Par exemple, vous pouvez tout fetcher dans votre répertoire Assets, à l'exception des gifs avec :

$ git lfs fetch -I "Assets/**" -X "*.gif"

Les modèles « excludes » et « includes » prennent en charge les mêmes modèles que git lfs track et .gitignore. Vous pouvez rendre ces modèles permanents pour un dépôt spécifique en définissant les propriétés de configuration lfs.fetchinclude et lfs.fetchexclude :

$ git config lfs.fetchinclude "Assets/**"
$ git config lfs.fetchexclude "*.gif"

Ces paramètres peuvent également s'appliquer à chaque dépôt sur votre système en ajoutant l'option --global.

Verrouillage de fichiers Git LFS

Malheureusement, il n'y a généralement aucun moyen de résoudre les conflits de merge binaire. La méthode traditionnelle permettant d'éviter les conflits de merge dans les systèmes de contrôle de version consiste à verrouiller des fichiers. Git LFS ne prend pas encore en charge le verrouillage de fichiers. Toutefois, une proposition détaillée a été formulée pour implémenter le verrouillage de fichiers, et un travail d'implémentation a débuté. Nous devrions donc bientôt voir cette option dans une livraison Git LFS.

Jusqu'à présent, le meilleur moyen d'éviter les conflits de merge est de communiquer avec les membres de l'équipe avant d'apporter des changements à un fichier binaire qu'ils sont susceptibles de modifier en même temps que vous.

Fonctionnement de Git LFS

Si vous souhaitez en savoir plus sur les filtres clean et smudge, les hooks pre-push et sur les concepts informatiques à la base de Git LFS, consultez cette présentation d'Atlassian sur Git LFS et LinuxCon 2016 :

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrez maintenant