Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022
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 da sua capacidade de gerir e alternar entre todas as versões de um arquivo localmente armazenadas.
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?
Submeter 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 comprometa 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 grandes ativos binários que são frequentemente atualizados.
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 comprimidos. 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 comprometa 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 passíveis de diferenciação, 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 um commit no seu repositório. Ele armazena o conteúdo do arquivo binário em armazenamento remoto separado.
Quando clona e alterna entre ramificações no seu repositório, o Git LFS transfere a versão correta 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 sua equipa a trabalhar em recursos grandes não passíveis de diferenciação, 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, você não verá os arquivos binários confirmados através do Git LFS quando clonar seu 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 ter o cliente Git LFS instalado enviará o ficheiro binário para o seu 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 utilizador arrasta um ficheiro binário através da interface web para um repositório configurado para o Git LFS, o ficheiro binário é registado no repositório e não os ponteiros que seriam registados 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.
Formato de ficheiro
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
Observação
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.