Git LFS vs. Git Padrão: Desempenho para Ativos Grandes
Compare o Git LFS com o Git padrão para ativos grandes, incluindo comportamento de clone, arquivos de ponteiro, rastreamento LFS e quando vale a pena usar o LFS.
Git LFS vs. Git Padrão: Desempenho para Ativos Grandes
Git LFS vs. Git padrão se torna uma questão real quando seu repositório começa a carregar grandes ativos binários. O código-fonte geralmente comprime e faz diff bem, mas vídeos, arquivos de design, texturas de jogos, arquivos de modelo e grandes conjuntos de dados podem tornar os clones lentos e o histórico difícil de limpar.
O Git Large File Storage, geralmente chamado de Git LFS, mantém o repositório Git normal mais leve substituindo arquivos selecionados por pequenos arquivos de ponteiro e armazenando o conteúdo real em um armazenamento de objetos LFS. Essa troca ajuda muitas equipes, mas não é mágica. Você ainda precisa escolher os arquivos certos, confirmar as regras de rastreamento e entender quando o LFS baixa o conteúdo.
O Gargalo de Desempenho do Git Padrão
O Git padrão armazena o conteúdo confirmado em seu banco de dados de objetos e mantém histórico suficiente para reconstruir cada versão confirmada. Isso funciona lindamente para arquivos de texto. Funciona mal quando o mesmo arquivo binário de 200 MB muda muitas vezes.
Dois problemas aparecem rapidamente:
- Formatos binários como JPEG, MP4, ZIP, PSD e artefatos compilados geralmente não se comprimem bem com delta.
- Arquivos deletados permanecem no histórico a menos que você reescreva o histórico.
- Novos clones pagam por erros antigos porque o histórico do Git ainda contém esses objetos antigos.
- Comandos de manutenção do repositório têm mais dados para inspecionar e empacotar.
Por exemplo, se uma equipe confirma um grande arquivo de design exportado a cada sprint, remover o arquivo do branch atual posteriormente não remove suas versões antigas do histórico. Novos desenvolvedores e workers de CI podem ainda baixar dados que ninguém usa ativamente.
Apresentando o Git Large File Storage (LFS)
O Git LFS é uma extensão que gerencia arquivos selecionados fora do banco de dados de objetos normal do Git. Seu repositório mantém um pequeno ponteiro de texto. O conteúdo real do arquivo reside no armazenamento LFS fornecido pelo seu host Git ou outro servidor LFS.
O Sistema de Ponteiros
Um ponteiro LFS se parece com isso:
version https://git-lfs.github.com/spec/v1
oid sha256:4c2d44962ff3c43734e56598c199589d8995a643...a89c89
size 104857600
Esse ponteiro é o que o Git normal vê. O cliente Git LFS baixa o conteúdo real do arquivo quando o checkout ou um comando LFS explícito precisa dele.
Comparação de Desempenho: LFS vs. Git Padrão
| Operação | Git Padrão | Git LFS |
|---|---|---|
| Clone inicial | Baixa o histórico do Git que inclui grandes objetos confirmados | Baixa o histórico do Git com arquivos de ponteiro; o conteúdo LFS pode ser baixado durante o checkout dependendo da configuração |
| Crescimento do repositório | Grandes binários podem inflar o histórico .git |
O histórico do Git permanece menor porque o conteúdo dos arquivos rastreados é externo |
| Checkout | Usa objetos já no banco de dados do Git | Pode precisar buscar objetos LFS para o commit verificado |
| Trabalhos de CI | Pode perder tempo baixando ativos históricos | Pode pular ou limitar downloads LFS quando as builds não precisam de ativos |
| Limpeza | Requer reescrita do histórico para remover blobs antigos confirmados | Ainda requer cuidado, mas novas versões rastreadas por LFS não incham o histórico normal do Git |
O detalhe importante é o comportamento do checkout. Um git clone simples com Git LFS instalado geralmente baixa os arquivos LFS necessários para o commit verificado. Se você quiser apenas ponteiros, use GIT_LFS_SKIP_SMUDGE=1 durante o clone e busque os arquivos depois com git lfs pull.
Quando Usar Git LFS
O Git LFS é uma boa escolha para arquivos que são grandes, binários e com expectativa de mudança. Exemplos comuns incluem:
*.psd,*.tiff,*.blende outros ativos de design ou 3D.*.mp4,*.mov,*.wave outros arquivos de mídia.- Grandes arquivos de modelo, fixtures de teste ou conjuntos de dados necessários para o projeto.
- Binários compilados apenas quando o projeto tem uma razão clara para versioná-los.
Não coloque todos os arquivos no LFS só porque você pode. Arquivos de texto, código-fonte, pequenos arquivos de configuração e arquivos que você quer que o Git faça diff normalmente devem permanecer no Git padrão.
Verifique os limites de armazenamento e largura de banda do seu provedor de hospedagem antes de adotar o LFS. GitHub, GitLab, Bitbucket e plataformas auto-hospedadas podem diferir em cotas, faturamento e comportamento de retenção.
Implementando Git LFS
Instale o cliente Git LFS, depois habilite seus hooks para seu usuário:
git lfs install
Rastreie os padrões que você quer que o LFS gerencie:
git lfs track "*.psd"
git lfs track "assets/*.mp4"
Esses comandos criam ou atualizam .gitattributes. Confirme esse arquivo com os ativos que ele afeta:
git add .gitattributes assets/
git commit -m "Rastrear ativos de design com Git LFS"
git push
Se um arquivo grande já foi confirmado no histórico normal do Git, rastreá-lo com LFS afeta apenas commits futuros. Para migrar o histórico existente, use uma ferramenta de migração como git lfs migrate import, e coordene cuidadosamente porque a reescrita do histórico altera os IDs dos commits.
Para clonar sem baixar o conteúdo LFS imediatamente, use:
GIT_LFS_SKIP_SMUDGE=1 git clone [email protected]:example/assets-heavy-repo.git
cd assets-heavy-repo
git lfs pull --include="assets/*.mp4"
Conclusão Prática
Use o Git padrão para código-fonte e pequenos arquivos de texto. Use o Git LFS para grandes ativos binários que pertencem ao repositório, mas não devem inflar o histórico normal do Git.
Para um repositório de equipe, adicione regras LFS cedo, confirme .gitattributes, documente como o CI lida com downloads LFS e verifique os limites LFS do seu host. Isso dá o benefício de desempenho sem surpreender os desenvolvedores durante clone, checkout ou builds de release.