Close

O que é o Git LFS?


O Git é um sistema de controle de versão distribuído, o que significa que todo o histórico do repositório é transferido para o cliente durante o processo de clonagem. Para projetos que contêm arquivos grandes, particularmente arquivos grandes que são modificados regularmente, esse clone inicial pode levar muito tempo, pois cada versão de cada arquivo precisa ser baixada pelo cliente. Git LFS (Large File Storage) é uma extensão do Git desenvolvida pela Atlassian, GitHub e alguns outros contribuidores de código aberto, que reduz o impacto de arquivos grandes em seu repositório baixando as versões relevantes deles preguiçosamente. Especificamente, arquivos grandes são baixados durante o processo de checkout, e não durante a clonagem ou a busca.

O que o Git LFS faz é substituir arquivos grandes em seu repositório por pequenos arquivos de ponteiro. Durante o uso normal, você nunca vai ver esses arquivos de ponteiro, pois eles são manipulados automaticamente pelo Git LFS:

1. Quando você adiciona um arquivo ao seu repositório, o Git LFS substitui seu conteúdo por um ponteiro e armazena o conteúdo do arquivo em um cache local do Git LFS.

Diagrama de adição do Git
bancos de dados
Material relacionado

Como mover um Repositório do Git completo

Logotipo do Bitbucket
VER SOLUÇÃO

Aprenda a usar o Git com o Bitbucket Cloud

2. Quando você envia novos commits para o servidor, todos os arquivos Git LFS referenciados pelos commits recém-enviados são transferidos do cache local do Git LFS para o armazenamento remoto do Git LFS vinculado ao repositório do Git.

Diagrama push do Git

Quando você faz o checkout de um commit que contém ponteiros do Git LFS, eles são substituídos por arquivos do cache local do Git LFS ou baixados do armazenamento remoto do Git LFS.

Diagrama push do Git

O Git LFS é simples: na sua cópia de trabalho, você vai ver apenas o conteúdo real do arquivo. Ou seja: você pode usar o Git LFS sem alterar seu fluxo de trabalho existente do Git; basta fazer o git checkout, a edição, o git add e o git commit normalmente. As operações git clone e git pull vão ser significativamente mais rápidas, pois você só baixa as versões de arquivos grandes referenciados por commits que você realmente fez checkout, em vez de todas as versões do arquivo que já existiram.

Para usar o Git LFS, você vai precisar de um host compatível com Git LFS, como o Bitbucket Cloud ou o Bitbucket Data Center. Os usuários do repositório vão precisar ter o cliente de linha de comando Git LFS instalado ou um cliente GUI compatível com Git LFS, como o Sourcetree. Curiosidade: Steve Streeting, o desenvolvedor da Atlassian que inventou o Sourcetree, também é um grande colaborador do projeto Git LFS, então o Sourcetree e o Git LFS trabalham juntos muito bem.

Instalando o Git LFS


1. Existem três maneiras fáceis de instalar o Git LFS:

a. Instale-o usando seu gerenciador de pacotes favorito. pacotes git-lfs estão disponíveis para Homebrew, MacPorts, DNF e packagecloud; ou

b. Faça o download e instale o Git LFS no site do projeto; ou

c. Instale o Sourcetree, um cliente de GUI de Git gratuito que vem com o Git LFS.

2. Quando o git-lfs estiver no caminho, execute git lfs install para inicializar o Git LFS (você pode pular esta etapa se tiver instalado o Sourcetree):

$ git lfs install Git LFS initialized. 

Você só vai precisar executar o git lfs install uma vez. Depois de inicializado para o seu sistema, o Git LFS vai inicializar automaticamente quando você clonar um repositório contendo conteúdo do Git LFS.

Criando um novo repositório Git LFS


Para criar um novo repositório compatível com Git LFS, você vai precisar executar o git lfs install depois de criar o repositório:

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

Esse comando instala um hook pre-push especial do Git em seu repositório que vai transferir arquivos Git LFS para o servidor quando você fizer o git push.

O Git LFS é ativado automaticamente para todos os repositórios do Bitbucket Cloud. Para o Bitbucket Data Center, você vai precisar habilitar o Git LFS nas configurações do seu repositório:

Git LFS com Bitbucket

Depois que o Git LFS for inicializado para seu repositório, você vai poder especificar quais arquivos rastrear usando o git lfs track.

Clonando um repositório Git LFS existente


Depois que o Git LFS estiver instalado, você vai poder clonar um repositório Git LFS normalmente usando git clone. No final do processo de clonagem, o Git vai fazer o checkout do branch padrão (em geral main), e todos os arquivos Git LFS necessários para concluir o processo de checkout vão ser baixados automaticamente para você. Por exemplo:

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

Há quatro PNGs neste repositório sendo rastreados pelo Git LFS. Ao executar o git clone, os arquivos do Git LFS são baixados um de cada vez, à medida que os arquivos de ponteiro são retirados do seu repositório.

Acelerando os clones


Se você estiver clonando um repositório com um grande número de arquivos LFS, o comando git lfs clone explícito oferece um desempenho muito melhor:

$ 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

Em vez de baixar os arquivos Git LFS um de cada vez, o comando git lfs clone aguarda até que o checkout seja concluído e, em seguida, baixa todos os arquivos Git LFS necessários como um lote. Assim ele aproveita os downloads paralelos e reduz drasticamente o número de solicitações HTTP e processos gerados (o que é especialmente importante para melhorar o desempenho no Windows).

Fazendo pull e checkout


Assim como a clonagem, você pode extrair de um repositório Git LFS usando um git pull normal. Todos os arquivos Git LFS necessários vão ser baixados como parte do processo de checkout automático assim que o pull for concluído:

$ 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

Nenhum comando explícito é necessário para recuperar o conteúdo do Git LFS. No entanto, se o checkout falhar por um motivo inesperado, você vai poder baixar qualquer conteúdo do Git LFS ausente para o commit atual com git lfs pull:

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

Acelerando os pulls


Como o git lfs clone, o git lfs pull baixa seus arquivos Git LFS como um lote. Se você sabe que um grande número de arquivos foi alterado desde a última vez que você puxou, você pode querer desabilitar o download automático do Git LFS durante o checkout e, em seguida, fazer o download em lote do seu conteúdo Git LFS com um git lfs pull explícito. Essa ação pode ser feita substituindo sua configuração do Git pela opção -c quando você invoca o git pull:

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

Já que é bastante coisa para digitar, você pode querer criar um alias Git simples para executar um pull em lote do Git e do Git LFS para você:

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

Assim o desempenho vai melhorar muito quando um grande número de arquivos Git LFS precisar ser baixado (de novo, especialmente no Windows).

Rastreando arquivos com o Git LFS


Quando você adiciona um novo tipo de arquivo grande ao seu repositório, você vai precisar dizer ao Git LFS para rastreá-lo especificando um padrão usando o comando git lfs track:

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

Observe que as aspas em torno de "e*.ogg" são importantes. A omissão delas vai fazer com que o caractere curinga seja expandido pelo shell, e entradas individuais vão ser criadas para cada arquivo .ogg no diretório atual:

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

Os padrões com suporte pelo Git LFS são os mesmos que o .gitignore, por exemplo:

# 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

Esses padrões são relativos ao diretório no qual você executou o comando git lfs track. Para manter as coisas simples, é melhor executar o git lfs track a partir da raiz do seu repositório. Observe que o Git LFS não suporta padrões negativos como .gitignore faz.

Depois de executar o git lfs track, você vai notar um novo arquivo chamado .gitattributes no diretório do qual você executou o comando. .gitattributes é um mecanismo do Git para vincular comportamentos especiais a certos padrões de arquivo. O Git LFS cria ou atualiza automaticamente o .gitattributes arquivos para vincular padrões de arquivos rastreados ao filtro Git LFS. No entanto, você vai precisar fazer o commit de todas as alterações no .gitattributes arquivo para seu repositório você mesmo:

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

Para facilitar a manutenção, é mais simples manter todos os padrões do Git LFS em um único arquivo .gitattributes sempre executando git lfs track a partir da raiz do seu repositório. No entanto, você pode exibir uma lista de todos os padrões que são atualmente rastreados pelo Git LFS (e os arquivos .gitattributes nos quais eles são definidos) invocando git lfs track sem argumentos:

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

Você pode parar de rastrear um padrão específico com o Git LFS apenas removendo a linha apropriada do seu arquivo .gitattributes, ou executando o 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

Depois de executar git lfs untrack, você vai ter que fazer o commit das alterações em .gitattributes de novo por conta própria.

Fazer commit e push


Você pode fazer commit e push normalmente para um repositório que contém conteúdo do Git LFS. Se você tiver feito o commit de alterações em arquivos rastreados pelo Git LFS, vai ver algumas saídas adicionais do git push à medida que o conteúdo do Git LFS for transferido para o servidor:

$ 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 a transferência dos arquivos LFS falhar por algum motivo, o push vai ser abortado, e você vai poder tentar novamente com segurança. Como o Git, o armazenamento Git LFS é endereçável ao conteúdo: o conteúdo é armazenado em uma chave que é um hash SHA-256 do próprio conteúdo. Ou seja: é sempre seguro tentar transferir arquivos Git LFS para o servidor de novo; você não pode substituir acidentalmente o conteúdo de um arquivo Git LFS com a versão errada.

Mover um repositório Git LFS entre hosts


Para migrar um repositório Git LFS de um provedor de hospedagem para outro, você pode usar uma combinação de git lfs fetch e git lfs push com a opção --all especificada.

Por exemplo, mover todos os repositórios Git e Git LFS de um remoto chamado github para um remoto chamado 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

Obtendo histórico extra do Git LFS


Normalmente, o Git LFS baixa apenas os arquivos necessários para commits de que você realmente faz o checkout no local. No entanto, você pode forçar o Git LFS a baixar conteúdo extra para outros branches modificados recentemente 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

Essa opção é útil para o download em lote do novo conteúdo do Git LFS enquanto você estiver no almoço, ou se estiver planejando revisar o trabalho de seus colegas de equipe e não conseguir baixar o conteúdo mais tarde devido à conectividade limitada com a Internet. Por exemplo, você pode querer executar git lfs fetch --recent antes de pular em um avião!

O Git LFS considera qualquer branch ou tag que contenha um commit mais recente do que sete dias. Você pode configurar o número de dias considerados recentes definindo a propriedade lfs.fetchrecentrefsdays:

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

Por padrão, git lfs fetch --recent só vai baixar o conteúdo do Git LFS para o commit na ponta de um branch ou tag recente.

git lfs - git lfs fetch --recent

No entanto, você pode configurar o Git LFS para baixar conteúdo para commits anteriores em branches e tags recentes configurando a propriedade lfs.fetchrecentcommitsdays:

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

Use essa configuração com cuidado: se você tiver branches muito dinâmicos, pode ficar com o download de uma grande quantidade de dados. No entanto, pode ser útil se você precisar revisar as alterações intersticiais em um branch, selecionar commits entre branches ou reescrever o histórico.

git lfs - git lfs fetch --recent commits

Conforme discutido em Movendo um repositório Git LFS entre hosts, você também pode optar por buscar todo o conteúdo do Git LFS para seu repositório com o 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

Excluindo arquivos locais do Git LFS


Você pode excluir arquivos do cache local do Git LFS com o comando git lfs prune:

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

Assim todos os arquivos Git LFS locais considerados antigos vão ser excluídos. Um arquivo antigo é qualquer arquivo não referenciado pelo:

  • commit do checkout atual
  • um commit que ainda não foi enviado (para a origem, ou para o que quer que o lfs.pruneremotetocheck esteja definido)
  • um commit recente

Por padrão, um commit recente é qualquer commit criado nos últimos dez dias. O cálculo é feito adicionando:

  • o valor da propriedade lfs.fetchrecentrefsdays discutida em Obtendo histórico extra do Git LFS (cujo padrão é sete); para
  • o valor da propriedade lfs.pruneoffsetdays (sendo que o padrão é de três)
git lfs remoção

Você pode configurar o deslocamento de remoção para reter o conteúdo do Git LFS por um período mais longo:

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

Ao contrário da coleta de lixo integrada do Git, o conteúdo do Git LFS não é removido automaticamente, portanto, executar o git lfs prune regularmente é uma boa ideia para manter o tamanho do repositório local baixo.

Você pode testar o efeito que uma operação de remoção vai ter com o git lfs prune --dry-run:

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

E exatamente quais objetos do Git LFS vão ser removidos com 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)

As strings hexadecimais longas produzidas pelo modo —verbose são hashes SHA-256 (também conhecidos como IDs de objeto ou OIDs) dos objetos Git LFS a serem removidos. Você pode usar as técnicas descritas em Localizando caminhos ou commits que fazem referência a um objeto Git LFS para saber mais sobre os objetos que vão ser removidos.

Como uma verificação de segurança adicional, você pode usar a opção --verify-remote para verificar se o armazenamento remoto do Git LFS tem uma cópia dos seus objetos Git LFS antes de serem removidos:

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

Assim o processo de remoção fica significativamente mais lento, mas você ganha a tranquilidade de saber que todos os objetos removidos podem ser recuperados do servidor. Você pode habilitar a opção --verify-remote permanentemente para o seu sistema configurando a propriedade lfs.pruneverifyremotealways globalmente:

$ git config --global lfs.pruneverifyremotealways true 

Ou você pode habilitar a verificação remota apenas para o repositório de contexto omitindo a opção --global do comando acima.

Excluindo arquivos remotos do Git LFS do servidor


O cliente de linha de comando Git LFS não suporta a remoção de arquivos do servidor, portanto, como você os exclui depende do seu provedor de hospedagem.

No Bitbucket Cloud, você pode visualizar e excluir arquivos Git LFS por meio das Configurações do repositório> Git LFS:

Bitbucket Cloud - excluir lfs do servidor

Observe que cada arquivo Git LFS é indexado por seu SHA-256 OID; os caminhos que fazem referência a cada arquivo não são visíveis por meio da interface do usuário. Esse comportamento ocorre porque pode haver muitos caminhos diferentes em muitos commits diferentes que podem se referir a um determinado objeto, portanto, procurá-los seria um processo muito lento.

Para determinar o que um determinado arquivo Git LFS realmente contém, você tem três opções:

  • ver a imagem de visualização do arquivo e o tipo de arquivo na coluna da esquerda da interface do usuário do Bitbucket Git LFS
  • baixar o arquivo usando o link na coluna da direita da interface do usuário do Bitbucket Git LFS -pesquisar commits que fazem referência ao SHA-256 OID do objeto Git LFS, conforme discutido na próxima seção

Localizando caminhos ou commits que fazem referência a um objeto Git LFS


Se você tiver um Git LFS SHA-256 OID, vai poder determinar quais commits fazem referência a ele com 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

Esse encantamento do git log gera um patch (-p) a partir de commits em qualquer branch (--all) que adiciona ou remove uma linha (-S) contendo a string especificada (um Git LFS SHA-256 OID).

O patch mostra o commit e o caminho para o objeto LFS, bem como quem o adicionou e quando foi feito o commit dele. Você pode simplesmente fazer o checkout do commit, e o Git LFS vai fazer o download do arquivo, se necessário, e colocá-lo em sua cópia de trabalho.

Se você suspeitar que um determinado objeto Git LFS está em seu HEAD atual ou em um branch específico, você pode usar git grep para encontrar o caminho do arquivo que faz referência a ele:

# 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

Você pode substituir HEAD ou power-ups por qualquer ref, commit ou árvore que contenha o objeto Git LFS.

Incluir/excluir arquivos Git LFS


Em algumas situações, você pode querer baixar apenas um subconjunto do conteúdo disponível do Git LFS para um commit específico. Por exemplo, ao configurar um build de integração contínua para executar testes de unidade, você pode precisar apenas do seu código-fonte, portanto, pode querer excluir arquivos pesados que não são necessários para criar seu código.

Você pode excluir um padrão ou subdiretório usando git lfs fetch -X (ou --exclude):

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

Como alternativa, você pode querer incluir apenas um padrão ou subdiretório específico. Por exemplo, um engenheiro de áudio pode buscar apenas arquivos ogg e wav com git lfs fetch -I (ou --include):

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

Se você combinar inclusões e exclusões, somente os arquivos que corresponderem a um padrão de inclusão e não corresponderem a um padrão de exclusão vão ser buscados. Por exemplo, você pode buscar tudo em seu diretório Assets, exceto gifs com:

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

Exclui e inclui suporte aos mesmos padrões que o git lfs track e .gitignore. Você pode tornar esses padrões permanentes para um repositório específico definindo as propriedades de configuração lfs.fetchinclude e lfs.fetchexclude:

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

Essas configurações também podem ser aplicadas a todos os repositórios do sistema, anexando a opção --global.

Bloqueando arquivos Git LFS


Infelizmente, não existe uma maneira fácil de resolver conflitos de binários no merge. Com o bloqueio de arquivos do Git LFS, você pode bloquear arquivos por extensão ou por nome de arquivo e impedir que arquivos binários sejam substituídos durante um merge.

Para aproveitar a característica de bloqueio de arquivos do LFS, primeiro você precisa informar ao Git quais tipos de arquivos podem ser bloqueados. No exemplo abaixo, a marcação `--lockable` é anexada ao comando `git lfs track` que armazena arquivos PSD no LFS e os marca como bloqueáveis.

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

Em seguida, adicione o seguinte ao seu .gitattributes :

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

Ao se preparar para fazer alterações em um arquivo LFS, você vai usar o comando lock para registrar o arquivo como bloqueado em seu servidor Git.

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

Quando não precisar mais do bloqueio de arquivo, você vai poder removê-lo usando o comando de desbloqueio do Git LFS.

$ git lfs unlock images/foo.psd

Os bloqueios de arquivo Git LFS podem ser substituídos, semelhante ao git push, usando uma marcação --force. Não use a marcação --force a menos que tenha absoluta certeza do que está fazendo.

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

Compartilhar este artigo

Leitura recomendada

Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.

Pessoas colaborando usando uma parede cheia de ferramentas

Blog do Bitbucket

Ilustração do DevOps

Caminho de aprendizagem de DevOps

Demonstrações de funções no Demo Den com parceiros da Atlassian

Como o Bitbucket Cloud funciona com o Atlassian Open DevOps

Inscreva-se para receber a newsletter de DevOps

Thank you for signing up