Gerenciar e armazenar arquivos grandes no Git

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

O Git ajuda a manter o volume do código-fonte pequeno porque as diferenças entre as versões são facilmente escolhidas e o código é facilmente compactado. Arquivos grandes que não compactam bem e que mudam inteiramente entre versões (como binários) apresentam problemas quando são armazenados em seus repositórios Git. O desempenho rápido do Git vem de sua capacidade de endereçar e alternar para todas as versões de um arquivo de seu armazenamento local.

Se você tiver arquivos grandes e indiffáveis em seu repositório (como binários), mantenha uma cópia completa desses arquivos em seu repositório sempre que confirmar uma alteração neles. Se houver muitas versões desses arquivos em seu repositório, elas aumentarão drasticamente o tempo para fazer check-out, ramificar, buscar e clonar seu código.

Quais tipos de arquivos você deve armazenar no Git?

Confirmar código-fonte, não dependências

Como sua equipe trabalha com editores e ferramentas para criar e atualizar arquivos, você deve colocar esses arquivos no Git para que sua equipe possa aproveitar os benefícios do fluxo de trabalho do Git. Não confirme outros tipos de arquivos em seu repositório: por exemplo, DLLs, arquivos de biblioteca e outras dependências que sua equipe não cria, mas seu código depende. Entregue esses arquivos por meio do gerenciamento de pacotes para seus sistemas.

O gerenciamento de pacotes agrupa suas dependências e instala os arquivos em seu sistema quando você implanta o pacote. Os pacotes são versão para garantir que o código testado em um ambiente seja executado da mesma forma em outro ambiente, desde que os ambientes tenham os mesmos pacotes instalados.

Não confirmar saídas

Não confirme os binários, logs, saída de rastreamento ou dados de diagnóstico de seus builds e testes. Essas são saídas do seu código, não do próprio código-fonte. Compartilhe logs e informações de rastreamento com sua equipe por meio de ferramentas de acompanhamento de item de trabalho ou por meio do compartilhamento de arquivos de equipe.

Armazenar fontes binárias pequenas e raramente atualizadas no Git

Os arquivos de origem binários que são raramente atualizados têm relativamente poucas versões confirmadas. Eles não ocuparão muito espaço se o tamanho do arquivo for pequeno. Imagens para a Web, ícones e outros ativos de arte menores podem se enquadrar nessa categoria. É melhor armazenar esses arquivos no Git com o restante da fonte para que sua equipe possa usar um fluxo de trabalho consistente.

Não confirme ativos binários grandes e atualizados com frequência

O Git gerencia uma versão principal de um arquivo e armazena apenas as diferenças dessa versão, em um processo conhecido como deltificação. A deltificação e a compactação de arquivos permitem que o Git armazene todo o histórico de código em seu repositório local. Binários grandes geralmente mudam inteiramente entre versões e geralmente já são compactados. Esses arquivos são difíceis de serem gerenciados pelo Git porque as diferenças entre as versões são grandes.

O Git deve armazenar todo o conteúdo de cada versão do arquivo e tem dificuldade em economizar espaço por meio de deltificação e compactação. Armazenar as versões completas desses arquivos faz com que o tamanho do repositório aumente ao longo do tempo. O aumento do tamanho do repositório reduz o desempenho da ramificação, aumenta os tempos de clone e expande os requisitos de armazenamento.

Estratégias para trabalhar com arquivos de origem binário grandes

• Não confirme arquivos compactados de dados. É melhor descompactar os arquivos e confirmar as fontes difusíveis. Permitir que o Git manipule a compactação dos dados em seu repositório.
• Evite confirmar código compilado e outras dependências binárias. Confirme a origem e crie as dependências ou use uma solução de gerenciamento de pacotes para fazer a versão e fornecer esses arquivos ao seu sistema.
• Armazene a configuração e outros dados estruturados em formatos de texto sem formatação difíveis, como JSON.

O que é o Git LFS?

Quando você tiver arquivos de origem com grandes diferenças entre versões e atualizações frequentes, poderá usar o LFS (Armazenamento de Arquivos Grandes) do Git para gerenciar esses tipos de arquivo. O Git LFS é uma extensão do Git que fornece dados que descrevem os arquivos grandes em uma confirmação para seu repositório. Ele armazena o conteúdo do arquivo binário em um armazenamento remoto separado.

Quando você clona e alterna ramificações em seu repositório, o Git LFS baixa a versão correta desse armazenamento remoto. As ferramentas de desenvolvimento locais funcionam de forma transparente com os arquivos como se fossem confirmados diretamente no seu repositório.

Benefícios

Um benefício do Git LFS é que sua equipe pode usar o fluxo de trabalho git de ponta a ponta familiar, independentemente dos arquivos que sua equipe cria. O LFS manipula arquivos grandes para evitar que eles afetem negativamente o repositório geral. Além disso, a partir da versão 2.0, o Git LFS dá suporte ao bloqueio de arquivos para ajudar sua equipe a trabalhar em ativos grandes e indiffáveis, como vídeos, sons e mapas de jogos.

O Git LFS é totalmente compatível e gratuito no Azure DevOps Services. Para usar o LFS com o Visual Studio, você precisa do Visual Studio 2015 Atualização 2 ou posterior. Basta seguir as instruções para instalar o cliente, configurar o acompanhamento do LFS para arquivos em seu repositório local e, em seguida, enviar suas alterações por push para o Azure Repos.

Limitações

O Git LFS tem algumas desvantagens que você deve considerar antes de adotá-lo:

• Cada cliente Git que sua equipe usa deve instalar o cliente Git LFS e entender sua configuração de acompanhamento.
• Se o cliente Git LFS não estiver instalado e configurado corretamente, você não verá os arquivos binários confirmados por meio do Git LFS ao clonar o repositório. O Git baixará os dados que descrevem o arquivo grande (que é o que o Git LFS confirma para o repositório) e não o arquivo binário. A confirmação de binários grandes sem o cliente Git LFS instalado enviará o binário por push para o repositório.
• O Git não pode mesclar as alterações de duas versões diferentes de um arquivo binário, mesmo que ambas as versões tenham um pai comum. Se duas pessoas estiverem trabalhando no mesmo arquivo ao mesmo tempo, elas deverão trabalhar juntas para reconciliar suas alterações para evitar substituir o trabalho do outro. O Git LFS fornece bloqueio de arquivo para ajudar. Os usuários ainda devem ter cuidado para sempre efetuar pull da cópia mais recente de um ativo binário antes de iniciar o trabalho.
• Atualmente, o Azure Repos não dá suporte ao uso do Secure Shell (SSH) em repositórios com arquivos controlados pelo Git LFS.
• Se um usuário arrastar um arquivo binário por meio da interface da Web para um repositório configurado para o Git LFS, o binário será confirmado para o repositório, não os ponteiros que seriam confirmados por meio do cliente Git LFS.
• Embora não haja uma restrição estrita de tamanho de arquivo, o espaço livre disponível do servidor e a carga de trabalho atual podem restringir o desempenho e a funcionalidade.
• O limite de tempo para um upload de arquivo é de uma hora.

Formato de arquivo

O arquivo gravado em seu repositório para um arquivo acompanhado do Git LFS tem algumas linhas com um par chave/valor em cada linha:

version https://git-lfs.github.com/spec/v1
oid a747cfbbef63fc0a3f5ffca332ae486ee7bf77c1d1b9b2de02e261ef97d085fe
size 4923023

Problemas conhecidos

Se você usar uma versão do LFS anterior à 2.4.0 com o Azure DevOps Server, será necessária uma etapa de instalação extra para autenticar por meio do NTLM em vez de Kerberos. Essa etapa não é mais necessária a partir do LFS 2.4.0 e é altamente recomendável que você atualize.