Dlaczego "git push helloworld +master: master"zamiast" git push helloworld"?

Question

Dlaczego "git push helloworld +master: master"zamiast" git push helloworld"?

I tried to push my (first ever!) git repo jak na początku:

$ git push helloworld

Ale mam to z powrotem:

To [email protected]:helloworld.git
 ! [rejected]        HEAD -> master (non-fast forward) error:
 failed to push some refs to '[email protected]:helloworld
git'

Więc znalazłem kolejne pytanie StackOverflow o "poprawione commity" i wypróbowałem sugestię stamtąd, nie wiedząc, czy mi to pomoże:

KaiserSosa@SMICHAELS /c/test/helloworld (master)
$ git push helloworld +master:master

Udało się!

Ale Nie wiem dlaczego to naprawiło mój problem: (

Może ktoś wyjaśnić, dlaczego to działa, ale "git push helloworld " nie?

9

git git-push

Author: Community, 2009-09-25

Source

1 answers

score 20 · Accepted Answer

Wygląda na to, że przepisałeś swoją historię (SHA-1 powiązaną z Twoim commitem) w gałęzi master.

Oznacza to, że nie można już naciskać w trybie szybkiego przewijania do przodu.

+master zmusza do pchnięcia:
Posiadając opcjonalny leading +, możesz powiedzieć gitowi, aby zaktualizował ref <dst>, nawet jeśli aktualizacja nie jest szybkim przewijaniem do przodu.

Uwaga: Może to być złe, jeśli ktoś jeszcze sklonował Twoje repozytorium, ponieważ nie będzie już w stanie po prostu wyciągnąć twojego repozytorium master branch bez żadnych konfliktów.
Zobacz również to więc odpowiedz na więcej .

Uwaga: Jak wspomniano przez Junio C. Hamano :

Istnieją dwa niezależne mechanizmy bezpieczeństwa:

Zabezpieczenie końca wysyłającego może być nadpisane przez" git push --force " i/lub przez użycie refspec poprzedzonego znakiem '+');

Zabezpieczenie końca odbioru może zostać nadpisane przez zmienną konfiguracyjną receive.denynonfastworwards repozytorium, które naciskasz do.

Ten ostatni domyślnie oznacza "unsafe" , ale jeśli Bezpieczeństwo jest aktywowane w repozytorium, wymuszanie od strony wysyłającej nie dezaktywuje go. IOW, oba końce muszą zgodzić się na niebezpieczne zachowanie.

Jak wspomniano w Git FAQ , możliwy sposób działania to:

Najbardziej prawdopodobnym powodem tego jest to, że musisz najpierw wyciągnąć z pilota. Możesz zobaczyć, jakie zmiany ma strona zdalna, pobierając najpierw, a następnie sprawdzam dziennik. Na przykład,

 $ git fetch origin
 $ git log master..origin/master

Wyświetli listę wszystkich zmian, które ma strona zdalna, a których nie ma Twoja strona.
Jeśli chcesz graficzną reprezentację, użyj gitk --left-right master...origin/master.
Strzałki po lewej to zmiany, które chcesz wcisnąć, strzałki po prawej to zmiany po stronie zdalnej.

Inne rozwiązanie (czyli to co zrobiłeś):

$ git push origin +branchname

To wymusi aktualizację. Jeśli nie masz pozwolenia, to czasami Będzie to praca:

$ git push origin :branchname
$ git push origin +branchname

Tzn. najpierw usuń gałąź zdalnie (często jest to dozwolone), a następnie ponownie wciśnij "nową" (lub być może przewiń) gałąź.

Uważaj, że jeśli przewijasz gałęzie, inni mogą mieć problem podczas ciągnięcia.
Istnieje szansa, że połączą się w gałęzi, którą pobrali z nową, którą opublikowałeś, skutecznie zachowując zmiany, których próbujesz się pozbyć.
Jednak tylko ich kopie będą mieć złe poprawki. Z tego powodu przewijanie gałęzi jest uważane za łagodnie antyspołeczne. Niemniej jednak często jest to właściwe.