Git non-fast-forward odrzucony
Mam wrażenie, że to pytanie było zadawane wiele razy, ale rozwiązaniem jest zazwyczaj " usunąłem katalog i ponownie wykonałem swoją pracę ze świeżą kasą."Zrobiłem commit i push, ale zdałem sobie sprawę, że odwołałem się do niewłaściwego numeru paragonu w wiadomości commit. Więc spojrzałem na SO dla szybkiego rozwiązanie i skończyło się wpisując następujące do terminala:
$ git reset --soft HEAD^
$ git commit -m "... correct message ..."
Jedynym problemem jest to, że otrzymuję następujący komunikat o błędzie:
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details.
Używam modelu git-flow i pracuję w dziale develop. Jak Mogę połączyć rzeczy z powrotem, aby git znów był szczęśliwy?
4 answers
Siła git push:
git push origin +develop
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-14 18:29:24
Jeśli wciśniesz commit na serwer, a następnie przepisasz go lokalnie (z git reset, git rebase, git filter-branch, lub jakiejkolwiek innej manipulacji historii), a następnie wepchnął ten przepisany commit z powrotem na serwer, będziesz spieprzyć każdego, kto wyciągnął. Oto przykład; powiedzmy, że popełniłeś, i pchnął go do serwera.
-*-*-A <-- master -*-*-A <-- origin/master
Teraz zdecydujesz się przepisać, w sposób, o którym wspomniałeś, Resetowanie i ponowne zatwierdzanie. Zauważ, że pozostawia to zwisające commit, A, które w końcu będą zbierane śmieci, ponieważ nie są osiągalne.
-*-*-A
\
A' <-- master
-*-*-A <-- origin/master
Jeśli ktoś inny, powiedzmy Fred, ściągnie master z serwera, gdy to robisz, będzie miał odniesienie do A, od którego może zacząć działać:]}
-*-*-A' <-- master -*-*-A <-- origin/master -*-*-A-B <-- fred/master
Teraz, jeśli byłbyś w stanie popchnąć swoje A' do origin/master, co stworzyłoby non-fast-forward, to nie miałoby A w swojej historii. Więc jeśli Fred spróbuje pociągnąć ponownie, nagle będzie musiał się połączyć i ponownie wprowadzić A commit:
-*-*-A' <-- master
-*-*-A <-- origin/master
-*-*-A-B-\
\ * <-- fred/master
A'--/
Jeśli Fred zauważy to, może wykonać rebase, który zapobiegnie ponownemu pojawieniu się commit A. Ale musiałby to zauważyć i pamiętać, aby to zrobić; a jeśli masz więcej niż jedną osobę, która ściągnęła w dół, wszystkie będą musiały zmienić bazę, aby uniknąć dodatkowego commita w drzewie.
Więc generalnie nie jest dobrym pomysłem, aby zmienić historię na repo, że inni ludzie wyciągają z. Jeśli jednak zdarzy ci się wiedzieć, że nikt inny nie jest po pobraniu z tego repo (na przykład, jest to Twój prywatny repo, lub masz tylko jednego innego dewelopera pracującego nad projektem, z którym możesz łatwo koordynować), możesz siłą zaktualizować, uruchamiając: {]}
git push -f
Lub
git push origin +master
Będą one zarówno ignorować czek dla non-fast-forward push, i aktualizować to, co jest na serwerze do nowej rewizji A', rezygnując z rewizji A więc w końcu będą zbierane śmieci.
Jest możliwe, że siły pchające są całkowicie wyłączona z opcją konfiguracji receive.denyNonFastForwards. Ta opcja jest domyślnie włączona w współdzielonych repozytoriach. W takim przypadku, jeśli naprawdę, naprawdę chcesz wymusić push, najlepszą opcją jest usunięcie gałęzi i ponowne jej utworzenie za pomocą git push origin :master; git push origin master:master. Jednak opcja denyNonFastForwards jest włączona z opisanego powyżej powodu; w repozytorium współdzielonym oznacza to, że teraz każdy, kto z niej korzysta, musi upewnić się, że przełączy się na nową historię.
Na współdzielonym repozytorium, generalnie lepiej jest po prostu wcisnąć nowe commity na górze, które naprawiają każdy problem, który masz; możesz użyć git revert aby wygenerować commity, które cofną zmiany poprzednich commitów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-06-24 14:35:32
Być może będziesz musiał zrobić git pull, które mogą automatycznie łączyć rzeczy za Ciebie. Wtedy możesz się zaangażować ponownie. Jeśli masz konflikty, poprosi Cię o ich rozwiązanie.
Pamiętaj, że musisz określić, z której gałęzi pobierać, jeśli nie zaktualizowałeś swojego gitconfig...
Na przykład:
git pull origin develop:develop
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-14 18:17:18
Używałem EGit i również miałem do czynienia z tym problemem. Po prostu próbowałem rebase bieżącej gałęzi i zadziałało.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-07-19 03:39:13