Solução de problemas com o limite de push de 2 GB

Saiba como contornar o limite de push de 2 GB.

Neste artigo

Sobre o limite de push

O GitHub tem um limite máximo de 2 GB para um único push. Você pode atingir esse limite ao tentar carregar repositórios muito grandes pela primeira vez, importar repositórios grandes de outras plataformas ou tentar reescrever o histórico de repositórios grandes existentes.

Se você atingir esse limite, verá uma das seguintes mensagens de erro:

  • fatal: the remote end hung up unexpectedly
  • remote: fatal: pack exceeds maximum allowed size

Você pode dividir seu push em partes menores ou excluir o histórico do Git e começar do zero. Se tiver feito um único commit maior que 2 GB e não puder excluir o histórico do Git e começar do zero, será necessário executar um rebase interativo para dividir o commit grande em vários commits menores.

Dividindo um push grande

Você pode evitar atingir o limite quebrando seu push em partes menores, cada uma das quais com menos de 2 GB de tamanho. Se um branch estiver dentro desse limite de tamanho, você poderá enviá-lo por push de uma só vez. No entanto, se um branch for maior que 2 GB, você precisará dividir o push em partes ainda menores e enviar apenas algumas confirmações de cada vez.

  1. Se você ainda não tiver configurado o remoto, adicione o repositório como um novo remoto. Para obter mais informações, confira "Gerenciar repositórios remote".

  2. Para encontrar confirmações adequadas espalhadas ao longo do histórico da ramificação principal no seu repositório local, execute o seguinte comando:

    git log --oneline --reverse refs/heads/BRANCH-NAME | awk 'NR % 1000 == 0'

    Esse comando revela cada 1000° commit. Você pode aumentar ou diminuir o número para ajustar o tamanho da etapa.

  3. Envie por push cada um desses commits, um de cada vez, para seu repositório hospedado do GitHub.

    git push REMOTE-NAME <YOUR_COMMIT_SHA_NUMBER>:refs/heads/BRANCH-NAME

    Se você vir a mensagem remote: fatal: pack exceeds maximum allowed size, reduza o tamanho da etapa na etapa 2 e tente novamente.

  4. Passe pelo mesmo processo para cada confirmação identificada no histórico da etapa 2.

  5. Se esta for a primeira vez que esse repositório está sendo enviado por push para GitHub, execute um push de espelhamento final para garantir que todas as referências restantes sejam enviadas para cima.

    git push REMOTE-NAME  --mirror

    Se isso ainda for muito grande, você precisará fazer push outras ramificações em estágios usando as mesmas etapas.

Quando você estiver familiarizado com o procedimento, poderá automatizar as etapas 2 a 4 para simplificar o processo. Por exemplo:

step_commits=$(git log --oneline --reverse refs/heads/BRANCH-NAME | awk 'NR % 1000 == 0')
echo "$step_commits" | while read commit message; do git push REMOTE-NAME  $commit:refs/heads/BRANCH-NAME; done

Começando do zero

Se o repositório não tiver histórico, ou seu commit inicial foi de mais de 2 GB por conta própria e você não se importar em redefinir o histórico do Git, também poderá começar do zero.

  1. Na sua cópia local, exclua a pasta oculta .git para remover todo o histórico anterior do Git e converta-o novamente em uma pasta normal cheia de arquivos.

  2. Criar uma pasta vazia.

  3. Execute git init e git lfs install na nova pasta e adicione o novo repositório vazio do GitHub como um remoto.

  4. Se você já usa o Git Large File Storage e tem todas as regras de controle do Git LFS que pretende usar já listadas no arquivo .gitattributes na pasta antiga, este deverá ser o primeiro arquivo a copiar para a nova pasta. Você deve garantir que as regras de controle estejam em vigor antes de adicionar quaisquer outros arquivos, para que não haja chance de que as coisas destinadas ao Git LFS recebam commit no armazenamento Git regular.

    Se você ainda não usa o Git LFS, pode ignorar essa etapa ou configurar as regras de controle que pretende usar no arquivo .gitattributes na nova pasta antes de copiar quaisquer outros arquivos. Para obter mais informações, confira "Configurar o GitLarge File Storage".

  5. Mova lotes de arquivos menores que 2 GB da pasta antiga para a nova. Depois que cada lote for movido, crie um commit e envie-o por push antes de mover o próximo lote. Você pode adotar uma abordagem cautelosa e manter cerca de 2 GB. Como alternativa, se tiver uma pasta com arquivos destinados ao Git LFS, poderá ignorar esses arquivos ao considerar o limite de 2 GB por lote.

Quando a pasta antiga estiver vazia, o repositório do GitHub deverá conter tudo. Se você estiver usando o Git LFS, todos os arquivos destinados ao Git LFS deverão ser enviados por push ao armazenamento do Git LFS.