Saiba como remover um binário grande do histórico do Git para gerenciar o tamanho dos repositórios clonados

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

O Git ganhou muita popularidade nos últimos anos como um repositório de código-fonte distribuído que permite que os usuários trabalhem com o repositório completo enquanto estão em um estado desconectado. Os benefícios do git estão bem documentados, mas o que acontece se você precisar "reverter o relógio" no repositório primário? Isso não é tão intuitivo e requer permissões elevadas, como você pode esperar para algo que afete todos os usuários do repositório.

Então, como você pode reverter o repositório central com segurança?

Cenário de problema

Imagine que você faça o commit de um arquivo grande, como um vídeo, no seu servidor git. Em um sistema de código-fonte tradicional, é conveniente armazenar tudo em um só lugar e, em seguida, baixar o que você precisa. No entanto, com o git, todo o repositório é clonado para o computador local de cada usuário. Com um arquivo grande, todos os usuários do projeto também precisarão baixar os arquivos grandes. Como cada arquivo grande subsequente é confirmado no servidor, o problema só aumenta, até que o repositório fique grande demais para ser eficiente para seus usuários. Para piorar as coisas, mesmo se você remover o infrator do repositório local e se comprometer novamente, o arquivo ainda existirá no histórico do repositório, o que significa que ele ainda será baixado para o computador local de todos como parte do histórico.

Adicionando um arquivo grande ao repositório local

Após fazer o commit do repositório local, o servidor também terá o arquivo grande

Congelar o repositório

Importante

As etapas a seguir removerão o vídeo do histórico do branch, mas o arquivo permanecerá no histórico de repositório quando você clonar o repositório do Azure Repos. Remover os arquivos do histórico do branch impede que os arquivos sejam atualizados, o que criará outra versão do arquivo grande em seu repositório. Saiba mais sobre como gerenciar arquivos grandes no Git e veja esta postagem no blog para obter uma explicação detalhada e uma solução alternativa para esse comportamento ao usar repositórios Git do Azure Repos.

Para corrigir isso, você precisa começar na origem, que, nesse caso, é o repositório do servidor. Peça à equipe para parar de fazer push para o repositório, mas se pushes adicionais acontecerem durante esse processo, você também precisará considerá-los para evitar a perda de dados.

Troca de base e push forçado

Se ninguém mais na equipe tiver feito alterações no repositório - geralmente por meio de um push - você poderá usar a rota fácil, na qual você essencialmente faz seu repositório local parecer da maneira que você deseja (ou seja, sem o arquivo grande), e forçar suas alterações no servidor.

Observação: talvez seja necessário clonar ou corrigir seu repositório local antes de iniciar este trabalho. Isso pode resultar em perda de trabalho ou alterações, portanto, prossiga com cautela.

Por padrão, você provavelmente só tem a capacidade de alterar seus arquivos do projeto local e o repositório, enviando por push suas alterações para o servidor, para que você não tenha a capacidade de fazer outras alterações, como exclusões ou trocas de base, no nível do servidor. Portanto, você precisará adquirir permissões para Forçar push nos projetos (preferencial) ou permissões de administrador com seu administrador, ou encontrar alguém que tenha essas permissões e vontade de ajudar. Para obter mais informações sobre permissões git, acesse aqui.

Em seguida, você precisa basear novamente o repositório.

1. Mas primeiro, use git log para encontrar os valores de hash SHA das confirmações mais recentes- você precisará dessas informações em um momento. Isso ocorre porque precisamos saber a confirmação de sucesso mais recente. Você obtém essas informações abrindo um prompt de comando git e digitando:

git log

Como alternativa, você pode obter o hash SHA exibindo o histórico do branch no Visual Studio Team Explorer.

2. Agora, abra um prompt de comando do Git.

3. Localize o código hash SHA de interesse.

4. Você precisará do SHA que começa com "25b4"

Lembre-se de que o Git usa ponteiros para determinar onde no repositório o branch principal ou atual está localizado. Por causa disso, o estado do repositório no qual você tem interesse estará em algum momento no passado. Para "voltar no tempo" e tornar esse estado desejado anterior o novo estado atual, você precisará usar o comando de rebase git:

git rebase -i <SHA hash of desired new current branch>

A opção -i fornece um pouco mais de segurança, pois ela abrirá o histórico em um editor (Minha implementação do Git na linha de comando do Windows abre o editor vi clássico, do qual você se lembrará se tiver trabalhado com um sistema baseado em Unix).

5. Para nosso exemplo, você digitaria:

git rebase -i 25b4

6. Depois que o editor aparecer, remova todas as linhas 'pick', exceto o branch que você deseja manter como seu novo principal. Quando parecer que tudo está conforme o desejado, em vi, digite ":w<enter>" para salvar ou "!q<enter>" para sair sem salvar.

Você estará alterando a(s) linha(s) que não deseja mais

7. Altere "pick" para "drop" conforme mostrado e digite ":w" (in vi) para salvar e ":q!" para iniciar a rebase

Agora digite git log novamente : o branch infrator deve estar ausente do log. Se estiver, você estará pronto para a etapa final, que exige permissões de administrador do projeto.

git log

Observe que o commit para o vídeo grande agora não existe mais no repositório local

8. Tipo: git push --force

Esse comando forçará seu repositório a tomar o lugar do repositório do servidor.

Use com cuidado, pois você pode facilmente perder dados no servidor!!

Observe que você deve se autenticar no servidor para que isso funcione

Se você estiver usando o Azure Repos, talvez seja necessário configurar uma credencial alternativa que não use caracteres especiais (como o "@" em um endereço de email). Para fazer isso, siga as instruções aqui.

Agora, o branch será permanentemente removido do servidor, e os clones e sincronizações subsequentes dos membros da equipe do projeto não farão o download dos arquivos grandes que você estava tentando remover. Os usuários precisarão baixar do servidor para garantir que estejam em sincronia com o estado recentemente atualizado do repositório do servidor.

Se os Usuários Tiverem Confirmações Mais Recentes

Se outros usuários já tiverem se comprometido com o repositório do servidor, você terá uma consideração adicional. Você deseja remover o branch que contém os arquivos grandes, mas não deseja perder as alterações feitas pela equipe. Para resolver isso, ao abrir o editor como parte da troca de base, examine cuidadosamente os commits. Certifique-se de que os commits que você deseja reter estão listados nas linhas 'pick'; exclua aqueles que você deseja remover, como em casos onde um grande arquivo foi adicionado.

Observe que, após o rebase, os outros usuários da equipe também precisarão rebasear para que todos tenham uma cópia consistente do repositório do servidor. Isso é uma dor para todos e normalmente deve ser evitado. Portanto, se você precisar remover um push conforme observado aqui, é importante coordenar com a equipe. Para obter detalhes completos sobre a troca de base, dê uma olhada na documentação oficial de troca de base aqui.

O mais importante é garantir que você saiba quais commits são desejados e indesejados. Estude o log do git ou o histórico em seu IDE (como o Visual Studio) e anote meticulosamente os hashes SHA para manter e aqueles para descartar.

Em cenários em que o arquivo grande existe há algum tempo e houve ramificações e mesclagens subsequentes, você pode ser capaz de remover o arquivo usando a opção git filter-branch . Se você quiser experimentar isso, siga as instruções aqui.

Considerações sobre práticas recomendadas

Ele economiza muito trabalho para garantir que os arquivos grandes fiquem fora do repositório principal em primeiro lugar. Com isso em mente, aqui estão algumas práticas recomendadas de bom senso para a equipe ter em mente:

O que fazer

• Comite alterações com frequência. Você sempre pode corrigi-las mais tarde com uma combinação de squash ou troca de base.
• Use branches para isolar suas alterações. As filiais são baratas e privadas, e a mesclagem é simples. Você também pode fazer backup de alterações em um branch enviando-as por push para o servidor.
• Certifique-se de usar uma convenção de nomenclatura ao publicar ramificações de temas. Dê o nome ao branch como "users/<alias>/<branchname>". Isso ajudará a agrupar seus branches e facilitará a identificação do "proprietário" por outras pessoas.
• Lembre-se sempre de enviar suas alterações por push. Commit != Checkin. (Commit + Push) == Checkin.
• Considere usar .gitignore para binários grandes para que eles não sejam adicionados ao repositório em primeiro lugar - mais informações aqui.
• Considere usar o controle de versão do NuGet ou do TFS para armazenar seus binários grandes.

O que não fazer

• Não faça rebase depois de realizar o push. Fazer a troca de base de commits enviados por push pode ser ruim porque força todos os outros no repositório a efetuar a troca de base de suas mudanças locais - e eles não ficarão felizes se precisarem fazer isso. Fazer a troca de base de commits enviados por push em seu próprio branch pessoal, mesmo que enviado por push, não representa uma grande vantagem a menos que outras pessoas estejam fazendo pull desses commits.
• Não faça commit de binários em seu repositório. O Git não compacta arquivos binários da maneira que o TFVC e, como todos os repositórios possuem todo o histórico, fazer commit dos arquivos binários implica em uma sobrecarga permanente.

Resumo

Às vezes, elementos indesejáveis, como arquivos grandes, são adicionados a um repositório e precisam ser removidos para manter o repositório limpo e leve. Você pode fazer isso organizando o repositório local usando o comando git rebase, e então usando o comando git push --force para substituir o repositório do servidor pelo repositório local.

Autores: Edward Fry e Jesse Houwing | Conectar-se com os autores e o ALM | DevOps Rangers aqui

(c) 2015 Microsoft Corporation. Todos os direitos reservados.ÿEste documento é fornecido "as-is". Informações e opiniões expressas neste documento, incluindo URL e outras referências a sites da Internet, podem ser alteradas sem aviso prévio. Você assume o risco ao utilizá-las.

Este documento não fornece direitos legais a qualquer propriedade intelectual em qualquer produto da Microsoft. Você pode copiar e usar este documento para suas finalidades internas de referência.