Partilhar via

Gerencie e armazene arquivos grandes no Git

  • Artigo

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

O Git ajuda a manter a pegada do seu código-fonte pequena 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 totalmente 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 a partir de seu armazenamento local.

Se você tiver arquivos grandes e não difusíveis em seu repositório (como binários), manterá uma cópia completa desses arquivos em seu repositório toda vez que confirmar uma alteração neles. Se existirem muitas versões desses arquivos em seu repositório, eles aumentam drasticamente o tempo para fazer check-out, ramificar, buscar e clonar seu código.

Que 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 do qual seu código depende. Entregue esses arquivos através 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 versionados 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 confirme saídas

Não confirme binários, logs, saída de rastreamento ou dados de diagnóstico de suas compilações e testes. Estas são saídas do seu código, não o código-fonte em si. Partilhe registos e informações de rastreio com a sua equipa através de ferramentas de controlo de itens de trabalho ou através da partilha de ficheiros de equipa.

Armazene fontes binárias pequenas e pouco atualizadas no Git

Os arquivos de origem binários que são atualizados com pouca frequência têm relativamente poucas versões confirmadas. Eles não ocupam 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 resto da sua fonte para que sua equipe possa usar um fluxo de trabalho consistente.

Importante

Mesmo binários pequenos podem causar problemas se forem atualizados com frequência. Por exemplo, 100 alterações em um arquivo binário de 100 KB usam tanto armazenamento quanto 10 alterações em um binário de 1 MB. Devido à frequência das atualizações, o binário menor diminuirá o desempenho de ramificação com mais frequência do que o binário grande.

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

O Git gerencia uma versão principal de um arquivo e, em seguida, armazena apenas as diferenças dessa versão, em um processo conhecido como deltification. A deltificação e a compactação de arquivos permitem que o Git armazene todo o seu histórico de código em seu repositório local. Binários grandes geralmente mudam inteiramente entre versões e muitas vezes já são compactados. Esses arquivos são difíceis para o Git gerenciar 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 através da deltificação e compressão. Armazenar as versões completas desses arquivos faz com que o tamanho do repositório aumente com o tempo. O aumento do tamanho do repositório reduz o desempenho de ramificação, aumenta os tempos de clonagem e expande os requisitos de armazenamento.

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

  • Não confirme arquivos compactados de dados. É melhor descompactar os arquivos e confirmar as fontes difusíveis. Deixe o Git lidar com a compactação dos dados em seu repositório.
  • Evite cometer 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 a versão e forneça esses arquivos ao seu sistema.
  • Armazene a configuração e outros dados estruturados em formatos de texto simples difusos, como JSON.

O que é o Git LFS?

Quando você tem arquivos de origem com grandes diferenças entre versões e atualizações frequentes, você pode usar o Git Large File Storage (LFS) 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 o seu repositório. Ele armazena o conteúdo do arquivo binário em armazenamento remoto separado.

Quando clona e troca de ramos no repositório, o Git LFS transfere a versão correta a partir desse armazenamento remoto. Suas ferramentas de desenvolvimento local trabalham de forma transparente com os arquivos como se estivessem comprometidos diretamente com seu repositório.

Benefícios

Um benefício do Git LFS é que sua equipe pode usar o fluxo de trabalho Git familiar de ponta a ponta, independentemente dos arquivos criados pela equipe. O LFS lida com 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 suporta o bloqueio de ficheiros para ajudar a equipa a trabalhar em recursos grandes que não podem ser processados com diff, como vídeos, sons e mapas de jogos.

O Git LFS é totalmente suportado e gratuito nos Serviços de DevOps do Azure. Para usar o LFS com o Visual Studio, você precisa do Visual Studio 2015 Update 2 ou posterior. Basta seguir as instruções para instalar o cliente, configurar o rastreamento do LFS para arquivos em seu repositório local e, em seguida, enviar suas alterações 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 rastreamento.
  • Se o cliente Git LFS não estiver instalado e configurado corretamente, não verá os ficheiros binários consolidados através do Git LFS quando clonar o repositório. O Git baixará os dados que descrevem o arquivo grande (que é o que o Git LFS compromete com o repo) e não o arquivo binário. Consolidar grandes ficheiros binários sem o cliente Git LFS instalado irá emiti-los para o repositório.
  • O Git não pode unir as alterações de duas versões diferentes de um ficheiro binário, mesmo que ambas as versões tenham um elemento principal comum. Se duas pessoas estiverem a trabalhar no mesmo ficheiro ao mesmo tempo, têm de trabalhar em conjunto para conciliar as alterações de modo a evitar a sobreposição do trabalho uma da outra. O Git LFS disponibiliza o bloqueio de ficheiros para ajudar. Mesmo assim, os utilizadores devem ter o cuidado de solicitar sempre a cópia mais recente de um recurso binário antes de iniciar o trabalho.
  • Atualmente, o Azure Repos não oferece suporte ao uso do Secure Shell (SSH) em repositórios com arquivos rastreados do Git LFS.
  • Se um usuário arrasta um arquivo binário através da interface web para um repositório configurado para o Git LFS, o binário é comprometido com o repositório - não com 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 prazo para o carregamento de um ficheiro é de uma hora.

File format

O arquivo gravado em seu repositório para um arquivo rastreado 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

Nota

A URL do GitHub incluída para o valor da versão define apenas o tipo de arquivo de ponteiro LFS. Não é um link para o seu arquivo binário.

Problemas conhecidos

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