O futuro dos arquivos grandes no Git é o próprio Git

• O projeto Git começou recentemente, de forma oficial, a resolver diretamente o problema de gerenciamento de arquivos grandes
• O Git LFS é uma solução paliativa que impõe vários custos e dependência de fornecedor aos usuários
• Com o recurso recente de partial clone, o próprio Git já consegue substituir a maior parte do papel do LFS
• No futuro, uma nova solução chamada large object promisor também está sendo preparada para integração ao Git oficial
• Com essas mudanças, a solução definitiva para o gerenciamento de arquivos grandes tende a convergir não para extensões externas, mas para o próprio Git

---

O problema dos arquivos grandes no Git e as mudanças em curso

• Se existe uma grande nêmesis do Git, ela é justamente os arquivos grandes
• Arquivos grandes incham os repositórios Git, reduzem a velocidade do git clone e também afetam negativamente a maioria dos ambientes de hospedagem

O surgimento do Git LFS e suas limitações

• Em 2015, o GitHub lançou o Git LFS para contornar o problema dos arquivos grandes
• Mas o próprio Git LFS adiciona nova complexidade e custos de armazenamento

• A comunidade Git vinha refletindo discretamente sobre a causa raiz do problema dos arquivos grandes e, nas releases oficiais mais recentes do Git, começou a surgir uma nova direção para gerenciar arquivos grandes sem LFS

O que já dá para fazer hoje: substituir o Git LFS por partial clone

• Como funciona o partial clone

  • Git LFS: os arquivos grandes ficam fora do repositório, e o trabalho acontece baixando apenas os arquivos necessários
  • Git partial clone (introduzido em 2017):
    • clona excluindo blobs acima de um tamanho desejado com a opção --filter
    • baixa do servidor apenas o arquivo grande necessário, somente quando preciso
      > Ao usar partial clone, não é necessário baixar previamente [ativos binários grandes] durante o clone e o fetch, o que reduz o tempo de download e o uso de disco
      > - Partial Clone Design Notes, git-scm.com

• Semelhanças entre partial clone e LFS

  • 1. Capacidade mínima no checkout: recebe apenas a versão mais recente e omite todo o histórico do arquivo
  • 2. Clonagem rápida: como não há transferência de arquivos grandes, o clone é mais veloz
  • 3. Configuração rápida: ao contrário do shallow clone, permite acesso ao histórico completo do projeto

• Exemplo de uso do partial clone

  • Caso real de velocidade de clonagem e uso de disco em um repositório com muito histórico de arquivos PNG grandes:
    • com clone normal, quase 4 minutos e 1,3 GB ocupados
    • com partial clone e limite de blob de 100 KB, clonagem em 6 segundos e 49 MB ocupados
    • em relação ao original, melhora de 97% na velocidade de clonagem e redução de 96% no tamanho do checkout

• Limitações do partial clone

  • Quando os dados filtrados são necessários (por exemplo, git diff, git blame, git checkout), o Git solicita os arquivos ao servidor
  • Essa é a mesma característica do Git LFS
  • Na prática, é raro haver necessidade de usar blame em arquivos binários

Os problemas do Git LFS

• Alta dependência de fornecedor: a implementação do GitHub suporta apenas seus próprios servidores, gerando cobrança e dependência
• Questão de custo: para armazenar 50 GB, o GitHub LFS custa US$ 40 por ano, enquanto o Amazon S3 custa US$ 13
• Difícil de reverter: depois de migrar para LFS, não é possível voltar ao estado anterior sem reescrever o histórico
• Custo contínuo de configuração: todos os colaboradores precisam instalar o LFS; se não instalarem, verão arquivos de metadados no lugar dos arquivos reais, o que gera confusão

Perspectivas futuras: Large Object Promisor

• Arquivos grandes também geram problemas de custo para plataformas de hospedagem como GitHub e GitLab
• O Git LFS reduz custos do servidor ao descarregar arquivos grandes para uma CDN

• O que é Large Object Promisor?

  • No início deste ano, o Git fez merge oficial de um recurso chamado large object promisor
  • Esse recurso reduz a carga de armazenamento do lado do servidor de forma semelhante ao LFS, mas reduz bastante a complexidade para o usuário
    > Esse esforço tem como objetivo melhorar o trabalho no lado do servidor, especialmente com blobs grandes que já estão compactados em formato binário
    > É uma solução alternativa ao Git LFS
    > – Large Object Promisors, git-scm.com

• Como funciona

  • 1. O usuário faz push de arquivos grandes para o host Git
  • 2. O host descarrega esses arquivos grandes para um promisor de backend
  • 3. No clone, o host Git fornece ao cliente as informações do promisor
  • 4. Quando necessário, o cliente baixa automaticamente os arquivos grandes a partir desse promisor

• Situação atual de adoção e desafios

  • O promisor para objetos grandes ainda está em desenvolvimento, e parte do código foi integrada ao Git em março de 2025
  • Implementações adicionais e discussões sobre issues em aberto estão em andamento no GitLab e em outros lugares
  • Ainda será preciso tempo até a adoção em massa
  • Por enquanto, a dependência do Git LFS para armazenar arquivos grandes continua inevitável
  • Quando o promisor se popularizar, a expectativa é que até o GitHub passe a permitir upload de arquivos acima de 100 MB

Conclusão: o futuro dos arquivos grandes no Git é o próprio Git

• O projeto Git continua pensando sem parar no problema dos arquivos grandes por você
• No momento, ainda é necessário usar o Git LFS
• Porém, com a evolução de partial clone e large object promisors, o Git LFS tende a se tornar gradualmente desnecessário, e em breve deve chegar a era em que será fácil gerenciar arquivos grandes apenas com Git
• No futuro, a última barreira para usar arquivos grandes talvez seja apenas a ideia de colocar uma biblioteca de MP3 dentro do Git