Erro Git ao tentar enviar - gancho de pré-recebimento recusado

Quando tento fazer uma alteração confirmada, recebo o seguinte erro ...

git.exe push -v --progress  "origin" iteration1:iteration1

remote: *********************************************************************
To ssh://git@mycogit/cit_pplus.git
! [remote rejected] iteration1 -> iteration1 (pre-receive hook declined)
error: failed to push some refs to 'ssh://git@mycogit/cit_pplus.git'

O que está acontecendo?

Você deve perguntar a quem mantém o repositório git@mycogit/cit_pplus.git.

Seus commits foram rejeitados pelo pre-receivegancho desse repositório (esse é um script configurável pelo usuário que visa analisar os commits recebidos e decidir se eles são bons o suficiente para serem aceitos no repositório).

Também é uma boa idéia pedir a essa pessoa para atualizar o gancho, para que ela imprima os motivos da rejeição.

Se o mantenedor é você mesmo, parece que você tem um problema com sua configuração no lado do servidor. Por favor, compartilhe mais informações então.

Aposto que você está tentando um impulso não-rápido e o gancho o bloqueia. Se for esse o caso, basta executar git pull --rebaseantes de pressionar para refazer as alterações locais na mais recente base de código.

O tamanho do arquivo é importante. Há um limite de ~ 120 MB para um único arquivo. No meu caso, .gitignore usando o Visual Studio tinha o arquivo listado, mas o arquivo ainda estava confirmado. Ao usar o git cli, podemos obter informações mais detalhadas sobre o erro.

o gancho de pré-recebimento recusado foi resultado do grande arquivo. Validando basicamente o push.

Para resolvê-lo, removi a última confirmação usando:

git reset --soft HEAD~1

Excluí o arquivo da confirmação.

Nota: Use HEAD ~ N para voltar ao número N de confirmações anteriores. (ou seja, 3, 4) Sempre use a opção --soft para manter as alterações na pasta

espero que ajude.

Isso pode ocorrer porque você não tinha o direito de acesso para enviar por push a uma ramificação como master. Você pode pedir ao mantenedor para lhe dar o direito de enviar confirmações.

No meu caso, recebi esta mensagem porque o ramo foi marcado como 'Protegido' no GitLab.

Recebi esta mensagem quando o servidor GitLab estava passando por algumas alterações. No dia seguinte, empurrar funcionou bem. De qualquer forma, como outros apontaram, verifique com seu mantenedor para ter certeza.

Eu tive esse problema ao tentar mesclar alterações com tamanho de arquivo maior do que o repositório remoto permitido (no meu caso, era o GitHub)

Eu encontrei esse mesmo problema.
O que resolveu para mim foi mudar para outro ramo e depois voltar para o original.

Não sei qual foi a causa do sublinhado, mas isso foi corrigido.

Bitbucket : verifique as permissões de Ramificação em Configurações (pode estar em 'Negar tudo'). Se isso não funcionar, basta clonar sua ramificação em uma nova ramificação local , enviar as alterações para o controle remoto (uma nova ramificação remota será criada) e criar um PR.

Caso ajude alguém:

Eu tinha um repositório em branco sem ramificação principal para desproteger (no Gitlab), portanto, antes de executar git push -u origin --all

• Eu tive que correr git push -u origin masterprimeiro
• desproteger o ramo mestre temporariamente
• empurre o resto ( --all& --tags)

Eu enfrentei o mesmo erro, ao verificar se tinha acesso de desenvolvedor e não podia publicar uma nova ramificação. A adição de direitos de acesso mais altos resolveu esse problema. (Gitlab)

Eu recebi esse erro com a essência do GitHub. Eu estava tentando enviar um commit com arquivos em subdiretórios. Acabou que a essência só pode ter arquivos no diretório raiz.

Remova a opção de ramificação protegida ou permita que funções adicionais, como desenvolvedores ou administradores, permitam que esses usuários com esse erro façam mesclagens e envios.

No meu caso, temos ganchos para mensagens de confirmação, nosso script de servidor aceita confirmações se elas tiverem o formato especial para mensagem de confirmação "<JIRA ID><Message>". Ele (gancho) recusa a confirmação se o respectivo ticket Jira não existir ou se houver alguns símbolos especiais na mensagem de confirmação. Eu enfrento esse erro quando adiciono /, [,> etc. em uma mensagem de confirmação, removendo-os bem.

Na verdade, isso acontece quando o YACC é ativado no lado do servidor no BitBucket. O YACC permite que nomes de problemas do JIRA sejam mencionados na mensagem de confirmação. Portanto, sempre que você confirmar algo, mantenha seu número JIRA na mensagem de confirmação e, além disso, você poderá adicionar sua própria mensagem.

Eu estava usando o GitKraken e criamos uma ramificação local, depois juntamos duas ramificações remotas e tentamos enviar a ramificação local à origem. Não funcionou com a mesma mensagem de erro.

A solução foi criar a ramificação local e enviá-la primeiro para a origem e, em seguida, fazer a mesclagem.

Problema: "PUSH Failed refs / head / - gancho de pré-recebimento recusado"

Eu enfrentei o problema de não poder enviar minhas alterações ao ramo de origem e qualquer coisa para dominar o ramo de um repositório de projeto específico, pois o tamanho desse repositório estava acima do limite rígido de 2 GB. Estava lançando o erro. Isso ocorreu porque empurramos os dados de teste sem saber para bitbucket de outras ramificações de teste.

PUSH Falhou refs / head / - gancho de pré-recebimento recusado

A verificação tentada é a mesma com outros repositórios de projetos e eles não estavam tendo problemas.

Consertar:

Meu colega percebeu que, quando clonamos o projeto de volta localmente, o tamanho do projeto era de 110 MB. Então começamos a limpar os ramos que mesclamos anteriormente e ramos ativos que não são mais necessários. Depois que a limpeza é feita em algumas filiais, percebemos que o tamanho do repositório caiu drasticamente de 2 GB para 120 MB. Em seguida, tentamos fazer as alterações no meu ramo e funcionou.

No meu caso, eu tinha um novo repositório, empurrei um ramo ('UCA-46', não 'mestre'), refizi-o, empurrei-o à força novamente e obtive o erro. Não havia ganchos da web. Eu executeigit pull --rebase como @ThiefMaster aconselhou, teve que rebase novamente e foi capaz de empurrar o ramo. Mas essa era uma maneira estranha e difícil.

Então, vi o gancho de pré-recebimento de erro de envio do Git recusado . Eu descobri que meu ramo ficou protegido . Tirei a proteção e pude forçar novamente.

Eu entendi isso ao tentar passar para uma instância dokku. Acontece que o disco estava cheio no meu servidor.

Correu: du -f

E o resultado foi:

Filesystem      Size  Used Avail Use% Mounted on
udev            476M     0  476M   0% /dev
tmpfs           100M  4.4M   95M   5% /run
/dev/xvda1      7.8G  7.4G  8.9M 100% /

Para mim, a autorização no servidor git remoto resolve o problema.

No meu caso, é porque eu adicionei acidentalmente um arquivo gigante ao meu envio não confirmado e não consegui me livrar dele, independentemente de qualquer puxar, redefinir ou reiniciar que fiz depois.

minha solução suja, mas viável, é renomear o diretório atual, clonar novamente o diretório para local e refletir as alterações manualmente no diretório local reclonado ...

Não parece bom, mas funciona ...

O erro para mim foi que o projeto não tinha ramificações criadas e minha função era desenvolvedor; portanto, não consegui criar nenhuma ramificação, solicite que elas me dêem as permissões pertinentes e tudo em ordem agora!

Uma ramificação padrão (por exemplo master) ainda não existe para o seu controle remoto. Então, primeiro você precisa criar uma masterramificação no servidor remoto git (por exemplo, criando um README.mdarquivo padrão ) e depois tentar pushtodas as suas ramificações locais existentes usando este comando:

git push -u origin --all

Para mim, tudo estava funcionando bem até que o Bitbucket mudou automaticamente sua política hoje (21 de abril de 2020). Isso acontece alinhado com um novo recurso recentemente introduzido hoje chamado Workspaces , então suspeito que tenha algo a ver com isso.

Solução alternativa : eu (como administrador) segui as instruções para adicionar o endereço de email aos usuários na interface do usuário (o email que você está usando pode ser encontradogit config --list

A especificação de uma versão do node.js. pode resolver o problema, como

{
  "name": "myapp",
  "description": "a really cool app",
  "version": "1.0.0",
  "engines": {
    "node": "10.3.0"
  }
}