Als ik probeer een wijziging door te voeren die ik heb vastgelegd, krijg ik de volgende foutmelding …
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'
Wat is er aan de hand?
Antwoord 1, autoriteit 100%
Je moet degene die de repo bijhoudt vragen op git@mycogit/cit_pplus.git.
Je commits zijn afgewezen door de pre-receivehookvan die repo (dat is een door de gebruiker configureerbaar script dat bedoeld is om inkomende commits te analyseren en te beslissen of ze goed genoeg zijn om in de repo te worden geaccepteerd).
Het is ook een goed idee om die persoon te vragen de hook bij te werken, zodat de redenen voor de afwijzing worden afgedrukt.
Als u zelf de beheerder bent, lijkt het erop dat u een probleem heeft met uw installatie aan de serverzijde. Deel dan meer informatie.
Antwoord 2, autoriteit 53%
Ik durf te wedden dat je een niet-snel-vooruit-push probeert en dat de haak het blokkeert. Als dat het geval is, voer je gewoon git pull --rebaseuit voordat je pusht om je lokale wijzigingen te rebasen op de nieuwste codebase.
Antwoord 3, autoriteit 47%
Bestandsgrootte is belangrijk. Er is een limiet van ~120 MB voor een enkel bestand. In mijn geval had .gitignore met Visual Studio het bestand vermeld, maar het bestand was nog steeds vastgelegd. Als we de git cli gebruiken, kunnen we meer gedetailleerde informatie over de fout krijgen.
pre-receive hook geweigerd was als gevolg van het grote bestand. In feite valideren van de push.
Om het op te lossen, heb ik het laatste commit gebruikt met behulp van:
git reset --soft HEAD~1
Ik heb vervolgens het bestand van de commit uitgesloten.
Opmerking:
Gebruik hoofd ~ n om terug te gaan naar n-nummer van eerdere commits. (d.w.z. 3, 4)
Gebruik altijd de SOFT-schakelaar om de wijzigingen in de map
te behouden
Ik hoop dat het helpt.
4, Autoriteit 13%
In mijn geval kreeg ik dit bericht omdat het filiaal was gemarkeerd als ‘beschermd’ in Gitlab.
5, Autoriteit 12%
Dit kan zijn omdat u niet de toegangsrecht had om een commit te duwen naar een tak, zoals master. U kunt de beheerder vragen om u het recht te geven om de commits te duwen.
6, Autoriteit 5%
Ik heb dit bericht gekregen toen de Gitlab Server enkele wijzigingen onderging. De volgende dag werkte duwen prima. Hoe dan ook, zoals anderen erop gewezen, controleer je met je beheerder om zeker te zijn.
7, Autoriteit 4%
ik heb hetzelfde probleem tegengekomen.
Wat het voor mij heeft opgelost, was om over te schakelen naar een andere tak en vervolgens terug naar de originele.
Niet zeker wat de onderstrepingoorzaak was, maar dit heeft het opgelost.
8, Autoriteit 3%
Ik had dit probleem bij het samenvoegen van wijzigingen met bestandsgrootte groter dan welke externe repository is toegestaan (in mijn geval het was Github)
9, Autoriteit 2%
in soms, omdat de branch die je pusht beschermd is, dus je kunt de beheerders van de repository vragen om de beschermingsstatus te veranderen. in git-lab , je kunt het vinden in
Settings > Repository > Protected Branches .
🙂
Antwoord 10, autoriteit 2%
Bitbucket: controleer op Branch-machtigingen in Instellingen (mogelijk op ‘Alles weigeren’).
Als dat niet werkt, kloon je je branch naar een nieuwe lokale branch, push je de wijzigingen naar de remote (een nieuwe remote branch wordt aangemaakt), en maak een PR aan.
Antwoord 11
Ik kreeg dezelfde fout te zien, toen ik controleerde dat ik ontwikkelaarstoegang had en geen nieuwe branch kon publiceren. Het toevoegen van hogere toegangsrechten loste dit probleem op. (Gitlab)
Antwoord 12
Ik kreeg deze fout met GitHub gist.
Ik probeerde een commit te pushen met bestanden in submappen.
Bleek dat de essentie alleen bestanden in de hoofdmap kan hebben.
Antwoord 13
Verwijder de beveiligde vertakkingsoptie of sta extra rollen toe, zoals ontwikkelaars of beheerders, zodat deze gebruikers die deze fout ervaren, merges en push kunnen doen.
Antwoord 14
In mijn geval hebben we hooks voor commit-berichten, ons serverscript accepteert commits als ze het speciale formaat hebben voor commit-berichten"<JIRA ID><Message>". It(hook) wijst de commit af als het betreffende Jira-ticket niet bestaat of als er enkele speciale symbolen in het commit-bericht staan. Ik kom deze fout tegen wanneer ik /, [, > etc. in een commit-bericht, het verwijderen van die werkt prima.
Antwoord 15
Dit gebeurt eigenlijk wanneer YACC is ingeschakeld aan de serverzijde in BitBucket. YACC maakt het mogelijk om JIRA-uitgiftenamen te vermelden in het commit-bericht. Dus als je iets commit, bewaar dan tenminste je JIRA-nummer in het commit-bericht en dan kun je bovendien je eigen bericht toevoegen.
Antwoord 16
Voor mij lost autorisatie op de externe git-server het probleem op.
Antwoord 17
Ik gebruikte GitKraken en we hebben een lokale branch gemaakt, daarna hebben we er twee remote branches in samengevoegd en toen probeerden we de lokale branch naar de origin te pushen. Het werkte niet met dezelfde foutmelding.
De oplossingwas om de lokale vertakking te maken en deze eerst naar de oorsprong te pushenen dan de samenvoeging uit te voeren.
Antwoord 18
Probleem: “PUSH mislukt refs/head/ – pre-receive hook geweigerd”
Ik heb het probleem gehad dat ik niet in staat was om mijn wijzigingen naar mijn origin branch te pushen en alles om de branch van een bepaalde projectrepository te masteren, omdat de grootte van die repo de harde limiet van 2GB overschreed. Het was het gooien van de fout.
Dat komt omdat we de testgegevens onbewust naar bitbucket hadden gepusht vanuit andere testtakken.
PUSH mislukt refs/head/ – pre-receive hook geweigerd
Dus geprobeerd te controleren of dat hetzelfde is met andere projectrepo’s en ze hadden geen problemen.
Oplossing:
Mijn collega merkte op dat toen we het project lokaal terugkloonden, de grootte van het project 110 MB was. Dus toen zijn we begonnen met het opschonen van de branches die we eerder hebben samengevoegd en actieve branches die niet meer nodig zijn.
Toen die opschoning eenmaal voor een paar takken was gedaan, realiseerden we ons dat de grootte van de repo drastisch daalde van 2 GB naar 120 MB. Toen probeerden we de wijzigingen naar mijn branch te pushen en het werkte.
Antwoord 19
In mijn geval kreeg ik deze foutmelding omdat er al een branch met dezelfde naam bestond. Het verwijderen van deze branch van de git-server zal dit oplossen.
Antwoord 20
In mijn geval was het probleem de beperking Rewriting branch history is not allowed.
Ga naar Repository settings -> Branch Permissionsbewerk de machtigingen van de geselecteerde vertakking en vink Allow rewriting branch history
aan
Antwoord 21
Ik kreeg dit toen ik probeerde te pushen naar een dokku-instantie. Blijkt dat de schijf vol was op mijn server.
Gelopen:
du -f
En het resultaat was:
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% /
Antwoord 22
In mijn geval is dat omdat ik per ongeluk een gigantisch bestand heb toegevoegd aan mijn niet-vastgelegde push en ik er niet vanaf kon komen, ongeacht wat ik daarna deed.
mijn vuile, maar werkbare oplossing is om de huidige map te hernoemen, de map opnieuw te klonen naar lokaal en de wijzigingen handmatig door te voeren naar de opnieuw gekloonde lokale map…
Het klinkt niet goed, maar het werkt…
Antwoord 23
De fout voor mij was dat er voor het project geen vertakkingen waren gemaakt en dat mijn rol ontwikkelaar was, dus ik kon geen vertakking maken, met het verzoek dat ze me de relevante rechten geven en alles nu in orde!
Antwoord 24
Een standaard branch (bijv. master) bestaat nog niet voor je remote. Dus je moet eerst een masterbranch maken in de git remote server (bijvoorbeeld door een standaard README.mdbestand aan te maken) en dan proberen te pushal je bestaande lokale vestigingen met dit commando:
git push -u origin --all
Antwoord 25
Voor mij werkte alles prima totdat Bitbucket vandaag automatisch hun beleid veranderde (21 april 2020). Dit komt toevallig overeen met een nieuwe functie die onlangs is geïntroduceerd, genaamd Werkruimten, dus ik vermoed dat het daar iets mee te maken heeft.
Tussenoplossing: ik (als beheerder) heb de instructies gevolgd om het e-mailadres toe te voegen aan gebruikers in de gebruikersinterface (het e-mailadres dat u gebruikt is te vinden git config --list
Antwoord 26
Ik heb dit bericht tijdens het proberen een afstandsbediening te verwijderen (Git Push Origin –Delete [Branch-Name]). Het probleem was dat de tak niet-verwijderbaar was in Bitbucket.
27
Ik had machtigingen probleem, na gegeven de juiste machtigingen was ik in staat om de inhoud te duwen. Ik duwde een bestaand project in een nieuwe Git Repo.
28
U moet naar de logboeken kijken. Ik kwam gewoon in dezelfde fout en realiseerde zich vanuit de logs die het was omdat ik een garen had. Slock en pakket-lock.json