Close

Cos'è Git LFS?


Git è un sistema di controllo delle versioni distribuito, il che significa che l'intera cronologia del repository viene trasferita al client durante il processo di clonazione. Per i progetti contenenti file di grandi dimensioni, in particolare file che vengono modificati regolarmente, questo clone iniziale può richiedere molto tempo, poiché ogni versione di ogni file deve essere scaricata dal client. Git LFS (Large File Storage) è un'estensione Git sviluppata da Atlassian, GitHub e alcuni altri collaboratori open source, che riduce l'impatto dei file di grandi dimensioni nel tuo repository scaricandone in modo più efficace le versioni pertinenti. In particolare, i file di grandi dimensioni vengono scaricati durante il processo di checkout anziché durante la clonazione o il recupero.

Git LFS lo fa sostituendo i file di grandi dimensioni nel tuo repository con piccoli file puntatori. Durante il normale utilizzo, non vedrai mai questi file puntatori poiché vengono gestiti automaticamente da Git LFS:

1. Quando aggiungi un file al tuo repository, Git LFS ne sostituisce il contenuto con un puntatore e memorizza il contenuto del file in una cache Git LFS locale.

Git add diagramma
Database
materiale correlato

Come spostare un repository Git completo

Logo di Bitbucket
Scopri la soluzione

Impara a utilizzare Git con Bitbucket Cloud

2. Quando esegui il push di nuovi commit al server, tutti i file Git LFS a cui fanno riferimento i commit appena inviati vengono trasferiti dalla tua cache Git LFS locale all'archivio Git LFS remoto collegato al tuo repository Git.

Diagramma push di Git

Quando effettui il checkout di un commit che contiene puntatori Git LFS, questi vengono sostituiti con file dalla cache locale di Git LFS o scaricati dall'archivio remoto di Git LFS.

Diagramma push di Git

Git LFS è perfetto: nella tua copia di lavoro vedrai solo il contenuto effettivo del tuo file. Ciò significa che puoi usare Git LFS senza modificare il tuo flusso di lavoro Git esistente; devi semplicemente eseguire git checkout, modificare, git add e git commit come di consueto. Le operazioni git clone e git pull saranno molto più veloci in quanto scaricherai solo le versioni di file di grandi dimensioni a cui fanno riferimento i commit di cui effettivamente esegui il checkout, piuttosto che tutte le versioni del file mai esistite.

Per usare Git LFS, avrai bisogno di un host compatibile con Git LFS come Bitbucket Cloud o Bitbucket Data Center. Gli utenti del repository dovranno avere installato il client a riga di comando Git LFS o un client con interfaccia grafica compatibile con Git LFS come Sourcetree. Curiosità: Steve Streeting, lo sviluppatore Atlassian che ha inventato Sourcetree, è anche uno dei principali contributori al progetto Git LFS, quindi Sourcetree e Git LFS lavorano piuttosto bene insieme.

Installazione di Git LFS


1. Esistono tre semplici modi per installare Git LFS:

a. Installarlo usando il tuo gestore di pacchetti preferito. I pacchetti git-lfs sono disponibili per Homebrew, MacPorts, dnf e packagecloud; oppure

b. Scaricare e installare Git LFS dal sito web del progetto; oppure

c. Installare Sourcetree, un client Git GUI gratuito fornito in bundle con Git LFS.

2. Una volta che git-lfs si trova sul tuo percorso, esegui git lfs install per inizializzare Git LFS (puoi saltare questo passaggio se hai installato Sourcetree):

$ git lfs install Git LFS initialized. 

Dovrai eseguire git lfs install solo una volta. Una volta inizializzato per il tuo sistema, Git LFS si avvierà automaticamente quando cloni un repository contenente contenuti Git LFS.

Creazione di un nuovo repository Git LFS


Per creare un nuovo repository compatibile con Git LFS, dovrai eseguire git lfs install dopo aver creato il repository:

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

In questo modo installi uno speciale hook Git pre-push nel tuo repository che trasferirà i file Git LFS sul server quando esegui il comando git push.

Git LFS è abilitato automaticamente per tutti i repository Bitbucket Cloud. Per Bitbucket Data Center, dovrai abilitare Git LFS nelle impostazioni del tuo repository:

Bitbucket Git LFS

Una volta che Git LFS è inizializzato per il tuo repository, puoi specificare quali file monitorare usando git lfs track.

Clonazione di un repository Git LFS esistente


Una volta installato Git LFS, puoi clonare un repository Git LFS normalmente usando git clone. Al termine del processo di clonazione, Git controllerà il branch predefinito (di solito main) e tutti i file Git LFS necessari per completare la procedura di checkout verranno scaricati automaticamente per te. Ad esempio:

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

Ci sono quattro file PNG in questo repository monitorati da Git LFS. Quando si esegue git clone, i file Git LFS vengono scaricati uno alla volta quando i file puntatori vengono estratti dal tuo repository.

Accelerazione dei cloni


Se stai clonando un repository con un gran numero di file LFS, il comando git lfs clone esplicito offre prestazioni molto migliori:

$ 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

Invece di scaricare i file Git LFS uno alla volta, il comando git lfs clone attende il completamento del checkout, quindi scarica tutti i file Git LFS richiesti come batch. L'operazione sfrutta i download parallelizzati e riduce drasticamente il numero di richieste e processi HTTP generati (il che è particolarmente importante per migliorare le prestazioni su Windows).

Estrazione e checkout


Proprio come la clonazione, puoi estrarre da un repository Git LFS usando un normale git pull. Tutti i file Git LFS necessari verranno scaricati come parte del processo di checkout automatico una volta completato l'estrazione:

$ 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

Non sono necessari comandi espliciti per recuperare contenuti Git LFS. Tuttavia, se il checkout fallisce per un motivo imprevisto, puoi scaricare qualsiasi contenuto Git LFS mancante per il commit corrente con git lfs pull:

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

Accelerazione dei pull


Come git lfs clone, git lfs pull scarica i tuoi file Git LFS in batch. Se sai che un gran numero di file è cambiato dall'ultima volta che hai estratto, potresti voler disabilitare il download automatico di Git LFS durante il checkout, quindi scaricare in batch i tuoi contenuti Git LFS con un git lfs pull esplicito. Questo può essere fatto sovrascrivendo la tua configurazione Git con l'opzione -c quando richiami git pull:

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

Dato che è piuttosto difficile digitare tutto, potresti voler creare un semplice alias Git per eseguire un pull Git e Git LFS in batch per te:

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

Ciò migliorerà notevolmente le prestazioni quando è necessario scaricare un gran numero di file Git LFS (di nuovo, soprattutto su Windows).

Monitoraggio dei file con Git LFS


Quando aggiungi un nuovo tipo di file di grandi dimensioni al tuo repository, devi dire a Git LFS di tracciarlo specificando uno schema usando il comando git lfs track:

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

Nota che le virgolette intorno a "*.ogg" sono importanti. Se le ometti, il carattere jolly verrà espanso dalla tua shell e verranno create singole voci per ogni file.ogg nella tua cartella attuale:

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

I modelli supportati da Git LFS sono gli stessi di quelli supportati da .gitignore, ad esempio:

# 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

Questi schemi sono relativi alla directory in cui hai eseguito il comando git lfs track. Per semplificare le cose, è meglio eseguire git lfs track dalla radice del tuo repository. Nota che Git LFS non supporta modelli negativi, mentre .gitignore sì.

Dopo aver eseguito git lfs track, noterai un nuovo file chiamato .gitattributes nella directory da cui hai eseguito il comando. .gitattributes è un meccanismo Git per associare comportamenti speciali a determinati modelli di file. Git LFS crea o aggiorna automaticamente file .gitattributes per associare i modelli di file tracciati al filtro Git LFS. Tuttavia, dovrai apportare tu stesso qualsiasi modifica ai file .gitattributes nel tuo 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"

Per facilità di manutenzione, è più semplice mantenere tutti i pattern Git LFS in un unico file .gitattributes eseguendo sempre git lfs track dalla radice del tuo repository. Tuttavia, puoi visualizzare un elenco di tutti i pattern attualmente tracciati da Git, LFS (e i file .gitattributes in cui sono definiti) richiamando git lfs track senza argomenti:

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

Puoi smettere di tracciare un particolare pattern con Git LFS semplicemente rimuovendo la riga appropriata dai tuoi file .gitattributes o eseguendo il comando 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

Dopo aver eseguito git lfs untrack, dovrai nuovamente confermare le modifiche in .gitattributes da te.

Commit e push


Puoi eseguire il commit e il push normalmente verso un repository che contiene contenuti Git LFS. Se hai apportato modifiche ai file tracciati da Git LFS, vedrai un output aggiuntivo da git push man mano che il contenuto di Git LFS viene trasferito sul server:

$ 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

Se il trasferimento dei file LFS fallisce per qualche motivo, il push verrà interrotto e potrai riprovare senza problemi. Come Git, lo storage Git LFS è indirizzabile ai contenuti: il contenuto è archiviato su una chiave che è un hash SHA-256 del contenuto stesso. Ciò significa che è sempre sicuro riprovare a trasferire file Git LFS sul server; non puoi sovrascrivere accidentalmente il contenuto di un file Git LFS con la versione sbagliata.

Spostamento di un repository Git LFS tra host


Per migrare un repository Git LFS da un provider di hosting a un altro, puoi usare una combinazione di git lfs fetch e git lfs push con --all option specificata.

Ad esempio, per spostare tutti i repository Git e Git LFS da un remoto chiamato github a un remoto chiamato 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

Recupero della cronologia aggiuntiva di Git LFS


Git LFS in genere scarica solo i file necessari per i commit effettivamente effettuati localmente. Tuttavia, puoi forzare Git LFS a scaricare contenuti extra per altri branch modificati di recente usando 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

Ciò è utile per scaricare in batch nuovi contenuti Git LFS mentre sei fuori a pranzo o se hai intenzione di esaminare il lavoro dei tuoi compagni di squadra e non potrai scaricare contenuti in seguito a causa della connettività Internet limitata. Ad esempio, potresti voler eseguire git lfs fetch --recent prima di imbarcarti su un aereo!

Git LFS considera recente qualsiasi branch o tag contenente un commit più recente di sette giorni. Puoi configurare il numero di giorni considerati recenti impostando la proprietà lfs.fetchrecentrefsdays:

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

Per impostazione predefinita, git lfs fetch --recent scaricherà i contenuti Git LFS per il commit solo all'inizio di un branch o tag recente.

git lfs - git lfs fetch --recent

Tuttavia, puoi configurare Git LFS per scaricare contenuti per i commit precedenti su branch e tag recenti configurando la proprietà lfs.fetchrecentcommitsdays:

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

Usa questa impostazione con attenzione: se hai branch in rapido movimento, ciò può comportare il download di un'enorme quantità di dati. Tuttavia può essere utile se devi rivedere le modifiche interstiziali in un branch, trovare commit specifici tra branch o riscrivere la cronologia.

git lfs - git lfs fetch --recent commits

Come discusso in Spostamento di un repository Git LFS tra host, puoi anche scegliere di recuperare tutti i contenuti Git LFS per il tuo repository con 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

Eliminazione di file Git LFS locali


Puoi eliminare file dalla tua cache Git LFS locale con il comando git lfs prune:

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

Questo eliminerà tutti i file Git LFS locali considerati vecchi. Un file vecchio è qualsiasi file a cui non fanno riferimento:

  • la conferma attualmente sottoposta a check-out
  • un commit che non è ancora stato inviato (all'origine, o qualsiasi cosa su cui lfs.pruneremotetocheck sia impostato)
  • un commit recente

Per impostazione predefinita, un commit recente è qualsiasi commit creato negli ultimi dieci giorni. Questo viene calcolato aggiungendo:

  • il valore della proprietà lfs.fetchrecentrefsdays descritta in Recupero della cronologia aggiuntiva di Git LFS (che per impostazione predefinita è sette); a
  • il valore della proprietà lfs.pruneoffsetdays (che per impostazione predefinita è tre)
git lfs prune

Puoi configurare l'offset prune per conservare i contenuti Git LFS per un periodo più lungo:

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

A differenza della garbage collection integrata di Git, il contenuto di Git LFS non viene eliminato automaticamente, quindi eseguire git lfs prune su base regolare è una buona idea per ridurre le dimensioni del repository locale.

Puoi testare l'effetto che avrà un'operazione prune con git lfs prune --dry-run:

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

E scegliere esattamente quali oggetti Git LFS verranno eliminati con 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)

Le stringhe esadecimali lunghe emesse dalla modalità --verbose sono hash SHA-256 (noti anche come ID oggetto o OID) degli oggetti Git LFS da eliminare. Puoi usare le tecniche descritte in Individuazione di percorsi o commit che fanno riferimento a un oggetto Git LFS per saperne di più sugli oggetti che verranno eliminati.

Come controllo di sicurezza aggiuntivo, puoi usare l'opzione --verify-remote per verificare se il repository remoto Git LFS ha una copia dei tuoi oggetti Git LFS prima che vengano eliminati:

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

Questo rallenta notevolmente il processo prune, ma ti permette di sapere che tutti gli oggetti saranno recuperabili dal server. Puoi abilitare l'opzione --verify-remote in modo permanente per il tuo sistema configurando la proprietà lfs.pruneverifyremotealways a livello globale:

$ git config --global lfs.pruneverifyremotealways true 

Oppure puoi abilitare la verifica remota solo per il repository contestuale omettendo l'opzione --global dal comando precedente.

Eliminazione di file Git LFS remoti dal server


Il client a riga di comando Git LFS non supporta la rimozione di file dal server, quindi il modo in cui li elimini dipende dal tuo provider di hosting.

In Bitbucket Cloud, puoi visualizzare ed eliminare i file Git LFS tramite Impostazioni del repository > Git LFS:

Bitbucket Cloud: eliminare lfs dal server

Nota che ogni file Git LFS è indicizzato dal relativo OID SHA-256; i percorsi che fanno riferimento a ciascun file non sono visibili tramite l'interfaccia utente. Questo perché potrebbero esserci molti percorsi diversi in molti commit diversi che possono riferirsi a un determinato oggetto, quindi cercarli sarebbe un processo molto lento.

Per determinare cosa contiene effettivamente un determinato file Git LFS, hai tre opzioni:

  • guardare l'immagine di anteprima e il tipo di file nella colonna sinistra dell'interfaccia utente Git LFS di Bitbucket
  • scaricare il file utilizzando il link nella colonna destra dell'interfaccia utente Bitbucket Git LFS: cerca i commit che fanno riferimento all'OID SHA-256 dell'oggetto Git LFS, come discusso nella sezione successiva

Individuazione di percorsi o commit che fanno riferimento a un oggetto Git LFS


Se hai un OID SHA-256 Git LFS, puoi determinare a quali commit fa riferimento con 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

Questa operazione git log genera una patch (-p) dai commit su qualsiasi branch (--all) che aggiunge o rimuove una riga (-S) contenente la stringa specificata (un OID Git LFS SHA-256).

La patch mostra il commit e il percorso dell'oggetto LFS, nonché chi l'ha aggiunto e quando è stato eseguito. Puoi semplicemente eseguire il checkout del commit e Git LFS scaricherà il file se necessario e lo inserirà nella tua copia di lavoro.

Se sospetti che un particolare oggetto Git LFS sia nel tuo HEAD attuale o in un particolare branch, puoi usare git grep per trovare il percorso del file di riferimento:

# 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

Puoi sostituire HEAD o power-up con qualsiasi riferimento, commit o albero che contenga l'oggetto Git LFS.

Inclusione/esclusione di file Git LFS


In alcune situazioni potresti voler scaricare solo un sottoinsieme dei contenuti Git LFS disponibili per un particolare commit. Ad esempio, quando configuri una build CI per eseguire test unitari, potresti aver bisogno solo del tuo codice sorgente, quindi potresti voler escludere i file pesanti che non sono necessari per eseguire la build del codice.

Puoi escludere uno schema o una sottocartella usando git lfs fetch -X (o --exclude):

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

In alternativa, potresti voler includere solo uno schema o una sottocartella particolare. Ad esempio, un tecnico del suono potrebbe recuperare solo file ogg e wav con git lfs fetch -I (o --include):

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

Se combini inclusioni ed esclusioni, verranno recuperati solo i file che corrispondono a uno schema di inclusione e non corrispondono a uno schema di esclusione. Ad esempio, puoi recuperare tutto nella tua directory Risorse tranne le gif con:

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

Esclusioni e inclusioni supportano gli stessi schemi di git lfs track e .gitignore. Puoi rendere permanenti questi schemi per un particolare repository impostando le proprietà di configurazione lfs.fetchinclude e lfs.fetchexclude:

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

Queste impostazioni possono essere applicate anche a tutti i repository del tuo sistema aggiungendo l'opzione --global.

Blocco dei file Git LFS


Sfortunatamente, non esiste un modo semplice per risolvere i conflitti di merge binario. Con il blocco dei file Git LFS, puoi bloccare i file per estensione o per nome e impedire che i file binari vengano sovrascritti durante un merge.

Per sfruttare la funzione di blocco dei file di LFS, devi prima dire a Git quali tipi di file sono bloccabili. Nell'esempio seguente, il flag "--lockable" viene aggiunto al comando "git lfs track" che memorizza entrambi i file PSD in LFS e li contrassegna come bloccabili.

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

Quindi aggiungi quanto segue al tuo file.gitattributes:

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

Quando ti prepari ad apportare modifiche a un file LFS, utilizzerai il comando lock per registrare il file come bloccato sul tuo server Git.

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

Quando non ti serve più il blocco del file, puoi rimuoverlo usando il comando di sblocco di Git LFS.

$ git lfs unlock images/foo.psd

I blocchi dei file Git LFS possono essere sovrascritti, in modo simile a git push, usando un flag --force. Non utilizzare il flag --force a meno che tu non sia assolutamente sicuro di come procedere.

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

Condividi l'articolo
Argomento successivo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Le persone collaborano utilizzando una parete piena di strumenti

Blog di Bitbucket

Illustrazione su Devops

Percorso di apprendimento DevOps

Funzione Demo Den per demo con esperti Atlassian

Come Bitbucket Cloud funziona con Atlassian Open DevOps

Iscriviti alla nostra newsletter DevOps

Thank you for signing up