Błąd Git podczas próby wypchnięcia - odrzucony hak odbioru wstępnego

Kiedy próbuję wprowadzić zatwierdzoną przeze mnie zmianę, pojawia się następujący błąd ...

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'

Co się dzieje?

Powinieneś zapytać, kto utrzymuje repo git@mycogit/cit_pplus.git.

Twoje zatwierdzenia zostały odrzucone przez pre-receivehak tego repozytorium (jest to konfigurowalny przez użytkownika skrypt, który ma analizować przychodzące commity i zdecydować, czy są wystarczająco dobre, aby zostać zaakceptowanym w repo).

Dobrym pomysłem jest również poproszenie tej osoby o zaktualizowanie haka, aby wydrukował powody odrzucenia.

Jeśli opiekun jest tobą sam, wygląda na to, że masz problem z konfiguracją po stronie serwera. W takim razie proszę podać więcej informacji.

Założę się, że próbujesz pchnięcia nie do przodu, a hak go blokuje. W takim przypadku po prostu uruchom git pull --rebaseprzed wypchnięciem, aby wprowadzić zmiany lokalne w najnowszej bazie kodu.

Rozmiar pliku jest ważny. Limit pojedynczego pliku wynosi ~ 120 MB. W moim przypadku plik .gitignore korzystający z programu Visual Studio miał plik na liście, ale plik został zatwierdzony. Korzystając z git cli, możemy uzyskać bardziej szczegółowe informacje o błędzie.

hak przed odebraniem został odrzucony w wyniku dużego pliku. Zasadniczo sprawdzanie poprawności wypychania.

Aby to rozwiązać, usunąłem ostatni zatwierdzenie, używając:

git reset --soft HEAD~1

Następnie wykluczyłem plik z zatwierdzenia.

Uwaga: Użyj HEAD ~ N, aby wrócić do N liczby poprzednich zatwierdzeń. (tj. 3, 4) Zawsze używaj przełącznika --soft, aby zachować zmiany w folderze

mam nadzieję, że to pomoże.

Może to być spowodowane tym, że nie masz prawa dostępu do wypychania zatwierdzenia do gałęzi, takiej jak master. Możesz poprosić opiekuna, aby dał ci prawo do wypychania zatwierdzeń.

W moim przypadku dostałem tę wiadomość, ponieważ gałąź została oznaczona jako „Protected” w GitLab.

Otrzymałem ten komunikat, gdy serwer GitLab przechodził pewne zmiany. Następnego dnia pchanie działało dobrze. W każdym razie, jak zauważyli inni, skontaktuj się ze swoim opiekunem, aby się upewnić.

Miałem ten problem podczas próby scalenia zmian o rozmiarze pliku większym niż dozwolone zdalne repozytorium (w moim przypadku był to GitHub)

Napotkałem ten sam problem.
To, co udało mi się rozwiązać, to przejście do innej gałęzi, a następnie powrót do pierwotnej.

Nie jestem pewien, co było przyczyną podkreślenia, ale to naprawiło.

Bitbucket : Sprawdź uprawnienia oddziału w Ustawieniach (może to być „Odrzuć wszystko”). Jeśli to nie zadziała, po prostu sklonuj swoją gałąź do nowej gałęzi lokalnej , wypchnij zmiany do zdalnego (zostanie utworzona nowa gałąź zdalna) i utwórz PR.

W przypadku, gdy pomaga to komuś:

Miałem puste repozytorium bez gałęzi master do ochrony (w Gitlab), więc przed uruchomieniem git push -u origin --all

• git push -u origin masterNajpierw musiałem biec
• tymczasowo odłączyć gałąź master
• popchnij resztę ( --alli --tags)

Napotkałem ten sam błąd, po sprawdzeniu miałem dostęp do programisty i nie mogłem opublikować nowego oddziału. Dodanie wyższych praw dostępu rozwiązało ten problem. (Gitlab)

Mam ten błąd z GistHub gist. Próbowałem wcisnąć zatwierdzenie z plikami w podkatalogach. Okazało się, że gist może mieć tylko pliki w katalogu głównym.

Usuń opcję chronionego oddziału lub zezwól na dodatkowe role, takie jak programiści lub administratorzy, aby umożliwić tym użytkownikom występowanie tego błędu wykonywanie połączeń i wypychanie.

W moim przypadku mamy haczyki dla komunikatów zatwierdzania, nasz skrypt serwera akceptuje zatwierdzenia, jeśli mają one specjalny format dla wiadomości zatwierdzania "<JIRA ID><Message>". (Hook) odrzuca zatwierdzenie, jeśli odpowiedni bilet Jira nie istnieje lub w komunikacie zatwierdzenia znajdują się specjalne symbole. Napotykam ten błąd, gdy dodam /, [,> itd. W komunikacie zatwierdzenia, usuwając te działa dobrze.

Dzieje się tak, gdy YACC jest włączony po stronie serwera w BitBucket. YACC umożliwia wymienienie nazw problemów JIRA w komunikacie zatwierdzenia. Dlatego za każdym razem, gdy cokolwiek popełniasz, zachowaj swój numer JIRA w komunikacie zatwierdzenia, a następnie możesz dodać własną wiadomość.

Korzystałem z GitKraken i stworzyliśmy lokalny oddział, następnie połączyliśmy w nim dwa zdalne oddziały, a następnie próbowaliśmy zepchnąć lokalny oddział do początku. Nie działa z tym samym komunikatem o błędzie.

Rozwiązaniem było utworzenie lokalnego oddziału i przesunąć go najpierw do pochodzenia, a następnie wykonać scalenie.

Problem: „PUSH Failed refs / head / - odmówiono odbioru wstępnego”

Napotkałem problem polegający na tym, że nie mogłem przesłać moich zmian do mojej gałęzi źródłowej ani niczego do master gałęzi konkretnego repozytorium projektu, ponieważ rozmiar tego repozytorium przekroczył twardy limit 2 GB. Zgłaszał błąd. To dlatego, że nieświadomie przekazaliśmy dane testowe do bitbucket z innych gałęzi testowych.

PUSH Failed refs / head / - odrzucony hak odbioru wstępnego

Próbowałem więc sprawdzić, czy to samo z innymi repozytoriami projektów i nie miały żadnych problemów.

Naprawić:

Mój kolega zauważył, że kiedy klonowaliśmy projekt lokalnie, jego rozmiar wynosił 110 MB. Więc wtedy zaczęliśmy czyścić gałęzie, które wcześniej scaliliśmy i aktywne gałęzie, które nie są już potrzebne. Po wyczyszczeniu kilku gałęzi zdaliśmy sobie sprawę, że rozmiar repozytorium drastycznie spadł z 2 GB do 120 MB. Potem próbowaliśmy wprowadzić zmiany do mojego oddziału i zadziałało.

W moim przypadku miałem nowe repozytorium, wypchnąłem gałąź („UCA-46”, a nie „master”), wydałem ją ponownie, forsowałem ponownie i dostałem błąd. Nie istniały żadne haki internetowe. I wykonany git pull --rebasejako @ThiefMaster poinformowała, musiał ponownie rebase i był w stanie popchnąć oddziału. Ale to był dziwny i trudny sposób.

Potem zobaczyłem, że hak błędu odbioru Git push został odrzucony . Odkryłem, że mój oddział został objęty ochroną . Usunąłem ochronę i mogłem ponownie naciskać.

Mam to przy próbie wypychania do instancji dokku. Okazało się, że dysk był pełny na moim serwerze.

Biegł: du -f

I wynik był:

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% /

Dla mnie autoryzacja na zdalnym serwerze git rozwiązuje problem.

W moim przypadku dzieje się tak dlatego, że przypadkowo dodałem gigantyczny plik do mojego niezaangażowanego pchnięcia i nie mogłem się go pozbyć, bez względu na to, jakie ściągnięcie, reset lub rm zrobiłem później.

moim brudnym rozwiązaniem, ale wykonalnym rozwiązaniem jest zmiana nazwy bieżącego katalogu, ponowne sklonowanie katalogu na lokalny i odzwierciedlenie zmian ręcznie w ponownie sklonowanym katalogu lokalnym ...

Nie brzmi dobrze, ale działa ...

Błąd polegał na tym, że w projekcie nie utworzono żadnych gałęzi, a moją rolą był programista, więc nie mogłem utworzyć żadnej gałęzi, poprosiłem o udzielenie mi odpowiednich uprawnień i wszystko w porządku!

Domyślna gałąź (np. master) Jeszcze nie istnieje dla twojego pilota. Więc najpierw musisz utworzyć mastergałąź na zdalnym serwerze git (np. Tworząc README.mdplik domyślny ), a następnie spróbuj wykonać pushwszystkie istniejące gałęzie lokalne za pomocą tego polecenia:

git push -u origin --all

Dla mnie wszystko działało dobrze, dopóki Bitbucket nie zmieni dziś automatycznie swojej polityki (21 kwietnia 2020 r.). Dzieje się tak, aby dostosować się do nowej funkcji, niedawno wprowadzonej dzisiaj, o nazwie Workspaces , więc podejrzewam, że ma to coś wspólnego z tym.

Obejście : I (jako administrator) postępowałem zgodnie z instrukcjami, aby dodać adres e-mail do użytkowników w interfejsie użytkownika (e-mail, którego używasz, można znaleźćgit config --list

Określenie wersji node.js może rozwiązać problem

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