Close

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.

Diagramme git add
Bases de données
Ressource connexe

Comment déplacer un dépôt Git complet

Logo Bitbucket
DÉCOUVRIR LA SOLUTION

Découvrir Git avec Bitbucket Cloud

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.

Diagramme git push

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.

Diagramme git push

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 Data Center. 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.

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 Git LFS.

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


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

# initialize Git
$ mkdir Atlasteroids
$ cd Atlasteroids
$ git init
Initialized empty Git repository in /Users/tpettersen/Atlasteroids/.git/
  
# initialize 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 Data Center, vous devrez activer Git LFS dans les paramètres de votre dépôt :

Bitbucket Git LFS

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 main), 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 check-out 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 :

# probably not what you want
$ 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 :

# track all .ogg files in any directory
$ git lfs track "*.ogg"
  
# track files named music.ogg in any directory
$ git lfs track "music.ogg"
  
# track all files in the Assets directory and all subdirectories
$ git lfs track "Assets/"
  
# track all files in the Assets directory but *not* subdirectories
$ git lfs track "Assets/*"
  
# track all ogg files in Assets/Audio
$ git lfs track "Assets/Audio/*.ogg"
  
# track all ogg files in any directory named Music
$ git lfs track "**/Music/*.ogg"
  
# track png files containing "xxhdpi" in their name, in any directory
$ 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 suivis 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  main -> main

Si le transfert des fichiers 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 l'option --all.

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 😉 :

# create a bare clone of the GitHub repository
$ git clone --bare git@github.com:kannonboy/atlasteroids.git
$ cd atlasteroids
  
# set up named remotes for Bitbucket and GitHub
$ git remote add bitbucket git@bitbucket.org:tpettersen/atlasteroids.git
$ git remote add github git@github.com:kannonboy/atlasteroids.git
  
# fetch all Git LFS content from GitHub
$ git lfs fetch --all github
 
# push all Git and Git LFS content to 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 main
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 :

# download Git LFS content for branches or tags updated in the last 10 days
$ 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 :

# download the latest 3 days of Git LFS content for each recent branch or tag
$ 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 :

# don't prune commits younger than four weeks (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 LFSGit LFS


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

$ 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 (OID Git LFS SHA-256).

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 :

# find a particular object by OID in HEAD
$ git grep 3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc HEAD
HEAD:Assets/Sprites/projectiles-spritesheet.png:oid sha256:3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
  
# find a particular object by OID on the "power-ups" branch
$ 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'existe pas de moyen simple de résoudre les conflits de merge binaire. Avec le verrouillage des fichiers de Git LFS, vous pouvez verrouiller les fichiers par extension ou par nom de fichier, et empêcher les fichiers binaires d'être écrasés lors d'un merge.

Afin de profiter de la fonctionnalité de verrouillage de fichiers de LFS, vous devez d'abord indiquer à Git quel type de fichiers sont verrouillables. Dans l'exemple ci-dessous, le flag « --lockable » est ajouté à la commande « git lfs track » qui stocke les fichiers PSD dans LFS et les marque comme verrouillables.

$ git lfs track "*.psd" --lockable

Ajoutez ensuite la commande suivante à votre fichier .gitattributes :

*.psd filter=lfs diff=lfs merge=lfs -text lockable

Lorsque vous vous préparez à apporter des changements à un fichier LFS, vous utiliserez la commande lock afin d'enregistrer le fichier comme verrouillé sur votre serveur Git.

$ git lfs lock images/foo.psd
Locked images/foo.psd

Une fois que vous n'avez plus besoin du verrou de fichier, vous pouvez le supprimer en utilisant la commande unlock de Git LFS.

$ git lfs unlock images/foo.psd

Les verrous de fichiers Git LFS peuvent être remplacés, comme pour git push, en utilisant un flag --force. N'utilisez pas le flag --force si vous n'êtes pas absolument sûr de ce que vous faites.

$ git lfs unlock images/foo.psd --force

Partager cet article

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Des personnes qui collaborent à l'aide d'un mur rempli d'outils

Le blog Bitbucket

Illustration DevOps

Parcours de formation DevOps

Démos Des démos avec des partenaires d'Atlassian

Fonctionnement de Bitbucket Cloud avec Atlassian Open DevOps

Inscrivez-vous à notre newsletter DevOps

Thank you for signing up