{"meta":{"title":"Solução de problemas do limite de push de 2 GiB","intro":"Saiba como contornar o limite de push de 2 GiB.","product":"Introdução","breadcrumbs":[{"href":"/pt/enterprise-cloud@latest/get-started","title":"Introdução"},{"href":"/pt/enterprise-cloud@latest/get-started/using-git","title":"Usar o Git"},{"href":"/pt/enterprise-cloud@latest/get-started/using-git/troubleshooting-the-2-gb-push-limit","title":"Limite máximo de push"}],"documentType":"article"},"body":"# Solução de problemas do limite de push de 2 GiB\n\nSaiba como contornar o limite de push de 2 GiB.\n\n## Sobre o limite de push\n\nGitHub tem um limite máximo de 2 GiB 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.\n\nSe você atingir esse limite, verá uma das seguintes mensagens de erro:\n\n* `fatal: the remote end hung up unexpectedly`\n* `remote: fatal: pack exceeds maximum allowed size`\n\nVocê pode dividir seu push em partes menores ou excluir o histórico do Git e começar do zero. Se você tiver feito uma única confirmação maior que 2 GiB e não puder excluir o histórico do Git e começar do zero, será necessário executar uma rebase interativa para dividir a confirmação grande em várias menores.\n\n## Dividindo um push grande\n\nVocê pode evitar atingir o limite dividindo seu push em partes menores, cada uma das quais deve ter menos de 2 GiB de tamanho. Se uma ramificação estiver dentro desse limite de tamanho, você poderá enviá-lo por push de uma só vez. No entanto, se uma ramificação for maior que 2 GiB, você precisará dividir o push em partes ainda menores e fazer push de apenas algumas confirmações por vez.\n\n1. Se você ainda não tiver configurado o remoto, adicione o repositório como um novo remoto. Para saber mais, confira [Gerenciar repositórios remote](/pt/enterprise-cloud@latest/get-started/git-basics/managing-remote-repositories#adding-a-remote-repository).\n\n2. Para encontrar confirmações adequadas espalhadas ao longo do histórico da ramificação principal no seu repositório local, execute o seguinte comando:\n\n   ```shell\n   git log --oneline --reverse refs/heads/BRANCH-NAME | awk 'NR % 1000 == 0'\n   ```\n\n   Esse comando revela cada 1000° confirmação. Você pode aumentar ou diminuir o número para ajustar o tamanho da etapa.\n\n3. Envie por push cada um dessas confirmações, um de cada vez, para seu repositório hospedado do GitHub.\n\n   ```shell\n   git push REMOTE-NAME +<YOUR_COMMIT_SHA_NUMBER>:refs/heads/BRANCH-NAME\n   ```\n\n   Se você vir a mensagem `remote: fatal: pack exceeds maximum allowed size`, reduza o tamanho da etapa na etapa 2 e tente novamente.\n\n4. Passe pelo mesmo processo para cada confirmação identificada no histórico da etapa 2.\n\n5. 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.\n\n   ```shell\n   git push REMOTE-NAME --mirror\n   ```\n\n   Se isso ainda for muito grande, você precisará fazer push outras ramificações em estágios usando as mesmas etapas.\n\nQuando você estiver familiarizado com o procedimento, poderá automatizar as etapas 2 a 4 para simplificar o processo. Por exemplo:\n\n```shell\nstep_commits=$(git log --oneline --reverse refs/heads/BRANCH-NAME | awk 'NR % 1000 == 0')\necho \"$step_commits\" | while read commit message; do git push REMOTE-NAME +$commit:refs/heads/BRANCH-NAME; done\n```\n\n## Começando do zero\n\nSe o repositório não tiver nenhum histórico ou a confirmação inicial tiver mais de 2 GiB sozinha, e você não se importar em redefinir o histórico do Git, também pode começar do zero.\n\n1. 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.\n\n2. Criar uma pasta vazia.\n\n3. Execute `git init` e `git lfs install` na nova pasta e adicione o novo repositório vazio do GitHub como um remoto.\n\n4. Se você já usa o Armazenamento de Arquivos Grandes do Git 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 a confirmação no armazenamento Git regular.\n\n   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 saber mais, confira [Configurar o GitLarge File Storage](/pt/enterprise-cloud@latest/repositories/working-with-files/managing-large-files/configuring-git-large-file-storage).\n\n5. Mova lotes de arquivos menores que 2 GiB da pasta antiga para a nova pasta. Depois que cada lote for movido, crie uma confirmação e envie-o por push antes de mover o próximo lote. Você pode adotar uma abordagem cautelosa e manter cerca de 2 GiB. Como alternativa, se você tiver uma pasta com arquivos destinados a Git LFS, você pode ignorar esses arquivos quando for calcular o limite de 2 GiB por lote.\n\nQuando 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."}