Skonfigurowałem zdalne nie-podstawowe „główne” repozytorium i sklonowałem je na moim komputerze. Wprowadziłem kilka lokalnych zmian, zaktualizowałem moje lokalne repozytorium i przesunąłem je z powrotem do mojego zdalnego repozytorium. Do tego momentu wszystko było w porządku.

Teraz musiałem coś zmienić w zdalnym repozytorium. Potem zmieniłem coś w moim lokalnym repozytorium. Uświadomiłem sobie, że zmiana zdalnego repo nie była potrzebna. Próbowałem więc git pushz lokalnego repozytorium do mojego zdalnego repozytorium, ale wystąpił błąd:

Aby zapobiec utracie historii, aktualizacje nie do szybkiego przewijania zostały odrzucone Scal zdalne zmiany przed ponownym przekazaniem dalej. Aby git push --helpuzyskać szczegółowe informacje, zobacz sekcję „Uwaga na temat szybkiego przewijania” .

Myślałem, że prawdopodobnie a

git push --force

zmusiłbym moją kopię lokalną do wypchnięcia zmian do zdalnej i uczynienia tego samego. Wymusza aktualizację , ale kiedy wracam do zdalnego repozytorium i dokonuję zatwierdzenia, zauważam, że pliki zawierają nieaktualne zmiany (te, które poprzednio miały główne repozytorium).

Jak wspomniałem w komentarzach do jednej z odpowiedzi :

[Próbowałem wymusić, ale wracając do serwera głównego, aby zapisać zmiany, dostaję przestarzałą inscenizację. Kiedy więc zatwierdzam, repozytoria nie są takie same. A kiedy próbuję ponownie użyć git push, pojawia się ten sam błąd.

Jak mogę rozwiązać ten problem?

Po prostu zrób:

git push origin <your_branch_name> --force

lub jeśli masz konkretne repozytorium:

git push https://git.... --force

Spowoduje to usunięcie poprzednich zatwierdzeń i przekazanie bieżącego.

Może to nie być właściwe, ale jeśli ktoś natknie się na tę stronę, pomyślał, że może chcieć prostego rozwiązania ...

Krótka flaga

Zauważ też, że -fto skrót --force, więc

git push origin <your_branch_name> -f

będzie również działać.

A jeśli push --forcenie działa, możesz to zrobić push --delete. Spójrz na 2 ^nd linii w tym przypadku:

git reset --hard HEAD~3  # reset current branch to 3 commits ago
git push origin master --delete  # do a very very bad bad thing
git push origin master  # regular push

Ale strzeż się...

Nigdy nie wracaj do publicznej historii gitów!

Innymi słowy:

• Nigdy nie forcepchaj publicznego repozytorium.
• Nie rób tego ani niczego, co może kogoś uszkodzić pull.
• Nigdy, resetani rewritehistorii w repozytorium, które ktoś mógł już wyciągnąć.

Oczywiście istnieją wyjątkowo rzadkie wyjątki nawet od tej reguły, ale w większości przypadków nie trzeba tego robić i spowoduje to problemy dla wszystkich innych.

Zamiast tego wykonaj cofnięcie.

I zawsze bądź ostrożny z tym, co popychasz do publicznego repozytorium . Cofanie:

git revert -n HEAD~3..HEAD  # prepare a new commit reverting last 3 commits
git commit -m "sorry - revert last 3 commits because I was not careful"
git push origin master  # regular push

W efekcie oba początkowe HEAD (z przywrócenia i zła resetowania ) będą zawierać te same pliki.

edytuj, aby dodać zaktualizowane informacje i więcej argumentów push --force

Rozważ siłę pchającą z dzierżawą zamiast pchania, ale nadal wolisz wycofać

Innym problemem push --forcemoże być sytuacja, gdy ktoś naciska na coś przed tobą, ale po tym, jak już go pobrałeś. Jeśli przeforsujesz wymuszoną wersję, zastąpisz teraz pracę innych .

git push --force-with-leasewprowadzony w git 1.8.5 ( dzięki komentarzowi @VonC do pytania) próbuje rozwiązać ten konkretny problem. Zasadniczo spowoduje błąd i nie wypchnie, jeśli pilot został zmodyfikowany od czasu ostatniego pobrania.

Jest to dobre, jeśli naprawdę jesteś pewien, że push --forcejest potrzebny, ale nadal chcesz zapobiec kolejnym problemom. Chciałbym powiedzieć, że powinno to być push --forcezachowanie domyślne . Ale wciąż nie jest to wymówka, aby wymusić push. Ludzie, którzy znaleźli się przed twoją bazą , nadal będą mieli wiele problemów, których można łatwo uniknąć, gdybyś zamiast tego cofnął się .

A ponieważ mówimy o git --pushinstancjach ...

Dlaczego ktoś miałby wymuszać nacisk?

@linquize przyniósł dobry przykład siły nacisku na komentarze: wrażliwe dane . Źle wyciekłeś danych, których nie należy wypychać. Jeśli jesteś wystarczająco szybki, możesz go „naprawić”* , wymuszając nacisk na górę.

*Dane nadal będą na pilocie chyba też zrobić śmieci zbierać lub oczyścić go jakoś . Istnieje również oczywisty potencjał, aby rozprzestrzenić go przez innych, którzy już go pobrali , ale masz pomysł.

Przede wszystkim nie wprowadzałbym żadnych zmian bezpośrednio w repozytorium „głównym”. Jeśli naprawdę chcesz mieć „główne” repozytorium, powinieneś je tylko naciskać, nigdy nie zmieniaj bezpośrednio.

Jeśli chodzi o występujący błąd, czy próbowałeś git pullz lokalnego repozytorium, a następnie git pushz repozytorium głównego? To, co obecnie robisz (jeśli dobrze to rozumiem), wymusza push, a następnie utratę zmian w „głównym” repozytorium. Najpierw powinieneś scalić zmiany lokalnie.

Jeśli jestem w mojej gałęzi lokalnej A i chcę wymusić wypchnięcie gałęzi lokalnej B do gałęzi źródłowej CI, można użyć następującej składni:

git push --force origin B:C

użyj następującego polecenia:

git push -f origin master

Naprawdę polecam:

• push tylko do głównego repozytorium

• upewnij się, że repozytorium główne jest repozytorium , aby nigdy nie mieć problemu z tym, że drzewo robocze repozytorium głównego nie jest zsynchronizowane z .gitbazą. Zobacz „ Jak przekazać lokalne repozytorium git na inny komputer? ”

• Jeśli musisz dokonać modyfikacji w głównym (nagim) repozytorium, sklonuj go (na głównym serwerze), dokonaj modyfikacji i odepchnij się do niego

Innymi słowy, utrzymuj dostęp do repozytorium zarówno z głównego serwera, jak i komputera lokalnego, aby mieć jedno repozytorium z / do którego można pobrać / pobrać.

To było nasze rozwiązanie do zastępowania wzorca w korporacyjnym repozytorium gitHub przy zachowaniu historii.

push -fopanowanie repozytoriów korporacyjnych jest często wyłączone, aby zachować historię oddziałów. To rozwiązanie działało dla nas.

git fetch desiredOrigin
git checkout -b master desiredOrigin/master // get origin master

git checkout currentBranch  // move to target branch
git merge -s ours master  // merge using ours over master
// vim will open for the commit message
git checkout master  // move to master
git merge currentBranch  // merge resolved changes into master

popchnij swój oddział desiredOrigini utwórz PR

Miałem to samo pytanie, ale w końcu je zrozumiałem. Najprawdopodobniej musisz wykonać następujące dwa polecenia git (zamieniając skrót na numer wersji git commit):

git checkout <hash>
git push -f HEAD:master