Close

Wat is Git LFS?


Git is een gedistribueerd versiebeheersysteem. Dat betekent dat de volledige geschiedenis van de repository tijdens het kloonproces naar de client wordt overgedragen. Voor projecten met grote bestanden, en met name grote bestanden die regelmatig worden aangepast, kan deze eerste kloon enorm veel tijd in beslag nemen, aangezien elke versie van elk bestand door de client moet worden gedownload. Git LFS (Large File Storage) is een Git-extensie die door Atlassian, GitHub en enkele andere open source-bijdragers is ontwikkeld en die de impact van grote bestanden in je repository vermindert door de relevante versies ervan lui te downloaden. Grote bestanden worden namelijk tijdens het uitcheckproces gedownload in plaats van tijdens het klonen of ophalen.

Git LFS doet dit door grote bestanden in je repository te vervangen door kleine pointer-bestanden. Bij normaal gebruik zul je deze pointer-bestanden nooit zien omdat ze automatisch worden verwerkt door Git LFS:

1. Wanneer je een bestand aan je repository toevoegt, vervangt Git LFS de inhoud ervan door een pointer en wordt de inhoud van het bestand in een lokale Git LFS-cache opgeslagen.

Voeg diagram toe in Git
Databases
gerelateerd materiaal

Een volledige Git-repository verplaatsen

Logo Bitbucket
Oplossing bekijken

Git leren met Bitbucket Cloud

Wanneer je nieuwe commits naar de server pusht, worden alle LFS-bestanden in Git waarnaar door de nieuw gepushte commits wordt verwezen, overgebracht van je lokale Git LFS-cache naar de externe Git LFS-cache die aan je Git-repository is gekoppeld.

Git-pushdiagram

Wanneer je een commit uitcheckt die Git LFS-pointers bevat, worden deze vervangen door bestanden uit je lokale Git LFS-cache of gedownload uit de externe Git LFS-store.

Push-diagram in Git

Git LFS is naadloos: in je werkkopie zie je alleen de daadwerkelijke bestandsinhoud. Dit betekent dat je Git LFS kunt gebruiken zonder je bestaande Git-workflow te wijzigen: je hoeft alleen maar git checkout, edit, git add en git commit te gebruiken, zoals gewoonlijk. De bewerkingen git clone en git pull zullen aanzienlijk sneller zijn omdat je alleen de versies downloadt van grote bestanden waarnaar wordt verwezen door commits die je daadwerkelijk bekijkt, in plaats van elke versie van het bestand die ooit bestond.

Om Git LFS te gebruiken, heb je een Git LFS-aware host nodig, zoals Bitbucket Cloud of Bitbucket Data Center. Gebruikers van de repository moeten de Git LFS-opdrachtregelclient hebben geïnstalleerd of een GUI-client gebruiken die Git LFS ondersteunt, zoals Sourcetree. Leuk weetje: Steve Streeting, de ontwikkelaar van Atlassian die Sourcetree heeft uitgevonden, levert ook een belangrijke bijdrage aan het Git LFS-project, dus Sourcetree en Git LFS werken vrij goed samen.

Git LFS installeren


1. Er zijn drie eenvoudige manieren om Git LFS te installeren:

a. Gebruik je favoriete pakketbeheerder. git-lfs-pakketten zijn beschikbaar voor Homebrew, MacPorts, dnf en packagecloud; of

b. Download en installeer Git LFS vanaf de projectwebsite; of

c. Installeer Sourcetree, een gratis Git GUI-client die wordt meegeleverd met Git LFS.

2. Zodra je git-lfs hebt, moet je git lfs install uitvoeren om Git LFS te initialiseren (je kunt deze stap overslaan als je Sourcetree hebt geïnstalleerd):

$ git lfs install Git LFS initialized. 

Je hoeft git lfs install maar één keer uit te voeren. Na de installatie op je systeem start Git LFS zichzelf automatisch op wanneer je een repository kloont die Git LFS-inhoud bevat.

Een nieuwe Git LFS-repository aanmaken


Om een nieuwe Git LFS-aware repository te maken, moet je git lfs install uitvoeren nadat je de repository hebt aangemaakt:

# 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.

Er wordt dan een speciale pre-push Git-hook in je repository geïnstalleerd die Git LFS-bestanden naar de server overbrengt wanneer je git push uitvoert.

Git LFS wordt automatisch ingeschakeld voor alle Bitbucket Cloud-repository's. Voor Bitbucket Data Center moet je Git LFS inschakelen in de instellingen van je repository:

Bitbucket Git LFS

Zodra Git LFS voor je repository is geïnitialiseerd, kun je met git lfs track aangeven welke bestanden je wilt traceren.

Een bestaande Git LFS-repository klonen


Zodra Git LFS is geïnstalleerd, kun je een Git LFS-repository op de gebruikelijke manier klonen met git clone. Aan het einde van het kloonproces checkt Git de standaardbranch uit (meestal de main-versie). Alle Git LFS-bestanden die nodig zijn om het uitcheckproces te voltooien, worden automatisch voor je gedownload. Bijvoorbeeld:

$ 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.

Er zijn vier PNGs in deze repository die worden bijgehouden door Git LFS. Wanneer git clone wordt uitgevoerd, worden Git LFS-bestanden een voor een gedownload terwijl de pointer-bestanden uit je repository worden uitgecheckt.

Klonen versnellen


Als je een repository met een groot aantal LFS-bestanden kloont, biedt de expliciete opdracht git lfs clone veel betere prestaties:

$ 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

In plaats van de Git LFS-bestanden een voor een te downloaden, wacht de opdracht git lfs clone tot het uitchecken is voltooid. Vervolgens worden alle vereiste Git LFS-bestanden als batch gedownload. Dit maakt gebruik van parallelle downloads en vermindert het aantal HTTP-verzoeken en -processen aanzienlijk (wat vooral belangrijk is om de prestaties op Windows te verbeteren).

Pullen en uitchecken


Net als bij klonen kun je met een normale git pull zaken ophalen uit een Git LFS-repository. Alle benodigde Git LFS-bestanden worden als onderdeel van het automatische uitcheckproces gedownload zodra de pull is voltooid:

$ 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

Er zijn geen expliciete opdrachten nodig om Git LFS-inhoud op te halen. Als het uitchecken echter om een onverwachte reden mislukt, kun je alle ontbrekende Git LFS-inhoud voor de huidige commit downloaden met git lfs pull:

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

Pulls versnellen


Net zoals git lfs clone downloadt git lfs pull je Git LFS-bestanden batchgewijs. Als je weet dat er een groot aantal bestanden is gewijzigd sinds de laatste keer dat je ze hebt opgehaald, kun je het automatisch downloaden via Git LFS uitschakelen tijdens het uitchecken. Vervolgens kun je je Git LFS-inhoud batchgewijs downloaden met een expliciete git lfs pull. Dit kun je doen door je Git-configuratie te negeren met de optie -c wanneer je git pull aanroept:

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

Aangezien dat nogal veel typewerk is, wil je misschien een eenvoudige Git-alias aanmaken om een Git- en Git LFS-pull in batches voor je uit te voeren:

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

Dit zal de prestaties aanzienlijk verbeteren als er een groot aantal Git LFS-bestanden moet worden gedownload (nogmaals, vooral in Windows).

Bestanden traceren met Git LFS


Als je een nieuw type groot bestand aan je repository toevoegt, moet je Git LFS vragen dat te traceren door een patroon op te geven met de opdracht git lfs track:

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

Let op: de aanhalingstekens rondom "*.ogg" zijn belangrijk. Als je ze weglaat, wordt de wildcard uitgebreid met je shell en worden er individuele items aangemaakt voor elk .ogg-bestand in je huidige map:

# probably not what you want
$ git lfs track *.ogg
Tracking explode.ogg
Tracking music.ogg
Tracking phaser.ogg

Git LFS ondersteunt dezelfde patronen die worden ondersteund door .gitignore, bijvoorbeeld:

# 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

Deze patronen hebben betrekking op de map waarin je de opdracht git lfs track hebt uitgevoerd. Om het simpel te houden, kun je het beste git lfs track uitvoeren vanuit de root van je repository. Let op: Git LFS ondersteunt geen negatieve patronen zoals .gitignore doet.

Nadat je git lfs track hebt uitgevoerd, zul je een nieuw bestand zien met de naam .gitattributes in de map waaruit je de opdracht hebt uitgevoerd. .gitattributes is een Git-mechanisme om speciaal gedrag te koppelen aan bepaalde bestandspatronen. Git LFS maakt of actualiseert automatisch .gitattributes-bestanden om patronen voor bijgehouden bestanden te koppelen aan de Git LFS-filter. Wijzigingen in het .gitattributes-bestand moet je echter wel zelf doorvoeren naar je repository:

$ 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"

Om het onderhoud te vereenvoudigen kun je het gemakkelijkst alle Git LFS-patronen in één .gitattributes-bestand bewaren door altijd git lfs track uit te voeren vanuit de hoofdmap van je repository. Je kunt echter een lijst weergeven van alle patronen die momenteel door Git LFS worden bijgehouden (en de .gitattributes-bestanden waarin ze zijn gedefinieerd) door git lfs track aan te roepen zonder argumenten:

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

Met Git LFS kun je het volgen van een bepaald patroon stoppen door simpelweg de juiste regel te verwijderen uit je .gitattributes-bestand of door de opdracht git lfs untrack uit te voeren:

$ 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

Nadat je git lfs untrack hebt uitgevoerd, moet je zelf de wijzigingen opnieuw doorvoeren in .gitattributes.

Committen en pushen


Je kunt zoals gewoonlijk committen en pushen naar een repository die Git LFS-inhoud bevat. Als je wijzigingen hebt doorgevoerd in bestanden die door Git LFS worden bijgehouden, zie je wat extra output van git push als de Git LFS-inhoud naar de server wordt overgebracht:

$ 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

Als het overzetten van de LFS-bestanden om een of andere reden mislukt, wordt de push afgebroken en kun je het veilig opnieuw proberen. Net als Git is Git LFS-opslag adresseerbaar voor inhoud: inhoud wordt opgeslagen onder een sleutel, die een SHA-256-hash is van de inhoud zelf. Dit betekent dat het altijd veilig is om opnieuw te proberen Git LFS-bestanden over te zetten naar de server: je kunt niet per ongeluk de inhoud van een Git LFS-bestand overschrijven met de verkeerde versie.

Een Git LFS-repository verplaatsen tussen hosts


Om een Git LFS-repository van de ene hostingprovider naar een andere te migreren, kun je een combinatie van git lfs fetch en git lfs push gebruiken, waarbij de optie --all is gespecificeerd.

Ga bijvoorbeeld als volgt te werk om alle Git- en Git LFS-repository's met de naam github naar een remote repo met de naam bitbucket 😉 te verplaatsen:

# 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

Extra Git LFS-geschiedenis ophalen


Git LFS downloadt doorgaans alleen de bestanden die nodig zijn voor commits die je daadwerkelijk lokaal uitcheckt. Je kunt Git LFS echter dwingen om extra content te downloaden voor andere recent aangepaste branches met 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

Dit is handig als je nieuwe Git LFS-content batchgewijs wilt downloaden terwijl je aan het lunchen bent, of als je van plan bent om werk van je teamgenoten te bekijken en later geen content kunt downloaden vanwege de beperkte internetverbinding. Misschien wil je bijvoorbeeld git lfs fetch --recent uitvoeren voordat je in het vliegtuig springt!

Git LFS beschouwt elke branch of tag met een commit die nieuwer dan zeven dagen is als recent. Je kunt het aantal dagen dat als recent wordt beschouwd instellen door de eigenschap lfs.fetchrecentrefsdays in te stellen:

# download Git LFS content for branches or tags updated in the last 10 days
$ git config lfs.fetchrecentrefsdays 10

git lfs fetch --recent downloadt standaard alleen Git LFS-inhoud voor de commit via het uiterste van een recente branch of tag.

git lfs - git lfs fetch --recent

Je kunt Git LFS echter configureren om content te downloaden voor eerdere commits voor recente branches en tags door de eigenschap lfs.fetchrecentcommitsdays te configureren:

# download the latest 3 days of Git LFS content for each recent branch or tag
$ git config lfs.fetchrecentcommitsdays 3

Wees voorzichtig met deze instelling: als je snel veranderende branches hebt, kan dit ertoe leiden dat er een enorme hoeveelheid gegevens wordt gedownload. Het kan echter nuttig zijn als je tussenliggende wijzigingen in een branch wilt bekijken, commits tussen branches eruit wilt pikken of de geschiedenis wilt herschrijven.

git lfs - git lfs fetch --recent commits

Zoals besproken in Een Git LFS-repository verplaatsen tussen hosts, kun je er ook voor kiezen om alle Git LFS-inhoud voor je repository op te halen met 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

Lokale Git LFS-bestanden verwijderen


Je kunt bestanden uit je lokale Git LFS-cache verwijderen met de opdracht git lfs prune:

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

Hiermee worden alle lokale Git LFS-bestanden verwijderd die als oud worden beschouwd. Een oud bestand is elk bestand waar niet naar wordt verwezen door:

  • de uitgecheckte commit
  • een commit die nog niet is gepusht (naar origin, of waar lfs.pruneremotetocheck ook op is ingesteld)
  • een recente commit

Een recente commit is standaard elke commit die in de afgelopen tien dagen is aangemaakt. Dit wordt berekend door het volgende toe te voegen:

  • de waarde van de eigenschap lfs.fetchrecentrefsdays zoals besproken in Extra Git LFS-geschiedenis ophalen (standaard zeven);
  • de waarde van de eigenschap lfs.pruneoffsetdays (standaard ingesteld op drie).
git lfs prune

Je kunt de prune-offset configureren om Git LFS-inhoud voor een langere periode te behouden:

# don't prune commits younger than four weeks (7 + 21)
$ git config lfs.pruneoffsetdays 21

In tegenstelling tot de ingebouwde 'afvalinzameling' van Git, wordt Git LFS-inhoud niet automatisch opgeschoond. Het is dan ook een goed idee om git lfs prune regelmatig uit te voeren om de grootte van je lokale repository beperkt te houden.

Je kunt testen welk effect een opschoningsbewerking zal hebben met git lfs prune --dry-run:

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

Test welke Git LFS-objecten precies worden opgeschoond met 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)

De lange hexadecimale tekenreeksen die in de modus --verbose worden uitgevoerd, zijn SHA-256-hashes (ook bekend als object-ID's of OID's) van de Git LFS-objecten die moeten worden opgeschoond. Je kunt de technieken gebruiken die in Paden of commits vinden die naar een Git LFS-object verwijzen worden beschreven om meer te weten te komen over de objecten die zullen worden opgeschoond.

Als extra veiligheidscontrole kun je de optie --verify-remote gebruiken om te controleren of de externe Git LFS-store een kopie van je Git LFS-objecten bevat voordat ze worden opgeschoond:

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

Dit maakt het opschoningsproces aanzienlijk langzamer, maar het geeft je gemoedsrust omdat je weet dat opgeschoonde voorwerpen op de server kunnen worden teruggehaald. Je kunt de optie --verify-remote permanent inschakelen voor je systeem door de eigenschap lfs.pruneverifyremotealways globaal te configureren:

$ git config --global lfs.pruneverifyremotealways true 

Of je kunt verificatie op afstand inschakelen voor alleen de context-repository door de optie --global uit het bovenstaande commando weg te laten.

Externe Git LFS-bestanden van de server verwijderen


De Git LFS-opdrachtregelclient ondersteunt het verwijderen van bestanden van de server niet. Hoe je ze verwijdert, hangt dus af van je hostingprovider.

In Bitbucket Cloud kun je Git LFS-bestanden bekijken en verwijderen via Repository-instellingen > Git LFS):

Bitbucket Cloud - LFS verwijderen van de server

Merk op dat elk Git LFS-bestand wordt geïndexeerd met zijn SHA-256-OID. De paden die naar elk bestand verwijzen, zijn niet zichtbaar via de gebruikersinterface. Dit komt omdat er bij veel verschillende commits tal van paden kunnen zijn die naar een bepaald object kunnen verwijzen. Het opzoeken zou dus een heel langzaam proces zijn.

Om te bepalen wat een bepaald Git LFS-bestand eigenlijk bevat, heb je drie opties:

  • Bekijk de voorbeeldweergave van het bestand en het bestandstype in de linkerkolom van de Bitbucket Git LFS-gebruikersinterface;
  • Download het bestand via de link in de rechterkolom van de Bitbucket Git LFS-gebruikersinterface. Zoek naar commits die verwijzen naar de SHA-256-OID van het Git LFS-object, zoals besproken in de volgende sectie.

Paden of commits vinden die naar een Git LFS-object verwijzen


Als je een Git LFS SHA-256 OID hebt, kun je bepalen naar welke commits wordt verwezen met 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

Deze git log-incantatie genereert een patch (-p) op basis van commits op elke branch (--all) die een regel (-S) toevoegt of verwijdert die de opgegeven tekenreeks bevat (een Git LFS SHA-256-OID).

De patch toont je de commit en het pad naar het LFS-object, en ook wie het heeft toegevoegd en wanneer het werd vastgelegd. Je kunt de commit gewoon uitchecken. Git LFS zal het bestand zo nodig downloaden en in je werkkopie plaatsen.

Als je vermoedt dat een bepaald Git LFS-object zich in je huidige HEAD of in een bepaalde branch bevindt, kun je git grep gebruiken om het bestandspad te vinden dat ernaar verwijst:

# 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

Je kunt HEAD of power-ups vervangen door elke ref-, commit- of boomstructuur die het Git LFS-object bevat.

Git LFS-bestanden in-/uitsluiten


In sommige situaties wil je misschien slechts een subset van de beschikbare Git LFS-inhoud downloaden voor een bepaalde commit. Als je bijvoorbeeld een CI-build configureert om eenheidstests uit te voeren, heb je mogelijk alleen je broncode nodig. Misschien wil je dus zware bestanden uitsluiten die niet nodig zijn om je code samen te stellen.

Je kunt een patroon of submap uitsluiten met git lfs fetch -X (of --exclude):

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

Als alternatief kun je misschien alleen een bepaald patroon of een bepaalde submap toevoegen. Een geluidstechnicus kan bijvoorbeeld enkel ogg- en wav-bestanden ophalen met git lfs fetch -I (of --include):

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

Als je insluiten en uitsluiten combineert, worden alleen bestanden opgehaald die overeenkomen met een 'include'-patroon en die niet overeenkomen met een 'exclude'-patroon. Je kunt bijvoorbeeld alles uit je Assets-map, behalve gifs ophalen met:

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

In- en uitsluitingen ondersteunen dezelfde patronen als git lfs track en .gitignore. Je kunt deze patronen permanent maken voor een bepaalde repository door de configuratie-eigenschappen lfs.fetchinclude en lfs.fetchexclude in te stellen:

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

Deze instellingen kunnen ook worden toegepast op elke repository in je systeem door de optie --global toe te voegen.

Git LFS-bestanden vergrendelen


Helaas is er geen eenvoudige manier om conflicten met binaire samenvoegingen op te lossen. Met Git LFS-bestandsvergrendeling kun je bestanden vergrendelen op basis van extensie of bestandsnaam en voorkomen dat binaire bestanden worden overschreven tijdens een samenvoeging.

Om van de functie voor bestandsvergrendeling in LFS te kunnen profiteren, moet je Git eerst vertellen welk type bestanden vergrendelbaar zijn. In het onderstaande voorbeeld wordt de markering '--lockable' aan de opdracht 'git lfs track' toegevoegd, waarbij PSD-bestanden zowel in LFS worden opgeslagen als als vergrendelbaar worden gemarkeerd.

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

Voeg daarna het volgende toe aan je .gitattributes-bestand:

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

Gebruik tijdens je voorbereidingen om wijzigingen in een LFS-bestand aan te brengen het vergrendelingscommando om het bestand als vergrendeld te registreren op je Git-server.

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

Als je het bestand niet meer hoeft te vergrendelen, kun je het verwijderen met de ontgrendelingsopdracht van Git LFS.

$ git lfs unlock images/foo.psd

Git LFS-bestandsvergrendeling kan worden opgeheven, vergelijkbaar met git push, met behulp van een --force-markering. Gebruik de markering --force niet tenzij je er absoluut zeker van bent dat je weet wat je doet.

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

Deel dit artikel
Volgend onderwerp

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Mensen die samenwerken met een muur vol tools

Bitbucket-blog

Toelichting DevOps

DevOps-leertraject

Demo Den Feature-demo's met Atlassian-experts

Hoe Bitbucket Cloud werkt met Atlassian Open DevOps

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up