Ich bin neu dabei git
und ich übe. Ich habe einen lokalen Zweig erstellt, aber ich habe das gesehen, als ich es tat git push
Mein Zweig wurde nicht in das Repository hochgeladen. Ich musste eigentlich machen: git push -u origin --all
.
Warum ist das? Ist eine Verzweigung nicht eine neue Änderung, die standardmäßig gepusht wird? Warum muss ich den zweiten Befehl ausführen?
Warum muss ich explizit einen neuen Zweig pushen?
Kratylos
VonC
Der eigentliche Grund ist, dass in einem neuen Repo (git init) dort ist keine Filiale (Nein master
überhaupt keine Verzweigung, null Verzweigungen)
Also, wenn Sie zum ersten Mal zu einem schieben leer Upstream-Repo (in der Regel a bloße), hat dieses Upstream-Repo keinen gleichnamigen Zweig.
Und:
- Die Standard-Push-Richtlinie war ‘
matching
‘ (drücke alle Zweige mit demselben Namen und erstelle sie, wenn sie nicht existieren), - Die Standard-Push-Richtlinie ist jetzt ‘
simple
‘ (Push nur den aktuellen Zweig und nur, wenn er einen ähnlich benannten Remote-Tracking-Zweig im Upstream hat, seit Git 1.7.11)
In beiden Fällen, da das vorgelagerte leere Repo keinen Zweig hat:
- es gibt noch keinen passenden benannten Zweig
- es gibt überhaupt keinen Upstream-Zweig (mit oder ohne gleichen Namen! Tracking oder nicht)
Das bedeutet Ihr Lokal Erste Push hat keine Ahnung:
- wohin schieben
- was zu pushen ist (da es keinen Upstream-Zweig finden kann, der entweder als Remote-Tracking-Zweig aufgezeichnet ist und/oder den gleichen Namen hat)
Sie müssen also mindestens Folgendes tun:
git push origin master
Aber wenn Sie nur das tun, dann:
- wird einen Upstream erstellen
master
Zweig auf dem Upstream (jetzt nicht leeres Repo): gut. - Gewohnheit Schallplatte dass die örtliche Niederlassung ‘
master
‘ muss in den Upstream verschoben werden (origin
) ‘master
‘ (Upstream-Zweig): schlecht.
Aus diesem Grund wird empfohlen, für den ersten Schub Folgendes zu tun:
git push -u origin master
Das wird aufnehmen origin/master
als Remote-Tracking-Zweig und ermöglicht es dem nächsten Push, automatisch zu pushen master
zu origin/master
.
git checkout master
git push
Und das funktioniert auch mit Push-Richtlinien ‘current
‘ oder ‘upstream
‘.
Jeweils nach der Initiale git push -u origin master
reicht ein einfacher Git-Push aus, um master weiterhin in den rechten Upstream-Zweig zu pushen.
-
Nach diesem Punkt der nächste
git push
erwartet auch, dass die Branche bereits existiert?– Kratylus
13. Juni 2013 um 21:29 Uhr
-
Jawohl. Es wird alle Updates für diesen Zweig in das Upstream-Repository verschieben.
– RyPeck
13. Juni 2013 um 21:30 Uhr
-
@Cratylus ja, wegen der neuen Standard-Push-Richtlinie ‘
simple
‘: Push zu einem beliebigen aufgezeichneten Upstream-Zweig, wenn dieser Upstream-Zweig hat den gleichen Namen wie der lokale. Eine einfachegit push
wird genug sein.– VonC
13. Juni 2013 um 21:38 Uhr
-
@ButtleButkus Danke. Ich habe den Link wiederhergestellt.
– VonC
12. November 2015 um 21:21 Uhr
-
Für den allgemeineren Fall des Fragestellers eines neuen Zweigs würden Sie ‘new_branch’ verwenden
git push --set-upstream origin new_branch
odergit push -u origin new_branch
kurz. Die-all
dass der Fragesteller die Benennung eines bestimmten neuen Zweigs umgangen hat, indem er alle Zweige eingeschlossen hat. Dies wird von + Klas Mellbourn in seiner Antwort behandelt.– Paul Masri-Stone
14. Dezember 2015 um 15:53 Uhr
John Culviner
Sie nicht, siehe unten
Ich finde dieses ‘Feature’ ziemlich nervig, da ich nicht versuche, Raketen zum Mond zu starten, sondern nur meinen verdammten Ast drücke. Du wahrscheinlich auch, sonst wärst du nicht hier!
Hier ist die Lösung: Wenn Sie möchten, dass der aktuelle Zweig implizit gepusht wird, unabhängig davon, ob dieser Zweig im Ursprung vorhanden ist, geben Sie diesen Befehl einfach einmal aus, und Sie werden es tun noch nie muss irgendwo nochmal:
git config --global push.default current
Wenn Sie also Verzweigungen wie folgt erstellen:
git checkout -b my-new-branch
und dann ein paar Commits machen und dann a
git push -u
um sie zum Ursprung zu bringen (in diesem Zweig) und es wird diesen Zweig für Sie erstellen, wenn er nicht existiert.
Beachten Sie, dass das Bit -u sicherstellt, dass sie verknüpft sind, wenn Sie später von diesem Zweig ziehen würden. Wenn Sie nicht vorhaben, den Zweig später zu ziehen (oder wenn Sie mit einem anderen Liner einverstanden sind), ist -u nicht erforderlich.
-
Wenn ich dies tue, wenn ich unmittelbar danach einen Git-Pull mache, sind die beiden Zweige nicht verknüpft. 🙁
– Aliso
26. Januar 2016 um 10:23 Uhr
-
Dies ist die einzige Antwort, die mein Problem behoben hat.
– Raymond Chenon
18. Mai 2017 um 9:34 Uhr
-
Um sie zu verknüpfen, verwenden Sie
git push -u
– Ben Creasy
28. Oktober 2017 um 1:06 Uhr
-
Danke! Diese Antwort sollte als schnelle und schmutzige Lösung akzeptiert werden. Ich bin mir ziemlich sicher, dass es der Absicht von OP am nächsten kommt.
– jungrrrr
19. Juli 2018 um 23:06 Uhr
-
> Ich versuche nicht, Raketen zum Mond zu starten. — JAWOHL.
– VCavallo
4. März 2019 um 23:00 Uhr
Klaus Melbourn
Ausgabe von git push
beim Schieben eines neuen Astes
> git checkout -b new_branch
Switched to a new branch 'new_branch'
> git push
fatal: The current branch new_branch has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin new_branch
Eine einfache git push
geht davon aus, dass bereits eine entfernte Verzweigung vorhanden ist, die von der aktuellen lokalen Verzweigung verfolgt wird. Wenn kein solcher entfernter Zweig vorhanden ist und Sie ihn erstellen möchten, müssen Sie dies mithilfe von angeben -u
(Kurzform von --set-upstream
) Flagge.
Warum ist das so? Ich denke, die Implementierer waren der Meinung, dass das Erstellen eines Zweigs auf der Fernbedienung eine so große Aktion ist, dass es schwierig sein sollte, dies versehentlich zu tun. git push
ist etwas, was Sie die ganze Zeit tun.
“Ist eine Verzweigung nicht eine neue Änderung, die standardmäßig gepusht wird?” Ich würde sagen, dass “eine Änderung” in Git ein Commit ist. Ein Branch ist ein Zeiger auf ein Commit. Für mich ist es sinnvoller, sich einen Push als etwas vorzustellen, das Commits zu den anderen Repositories hinüberschiebt. Welche Commits gepusht werden, hängt davon ab, in welchem Branch Sie sich befinden, und von der Tracking-Beziehung dieses Branch zu Branches auf der Remote.
Weitere Informationen zum Verfolgen von Zweigen finden Sie im Kapitel „Remote Branches“ des Pro Git-Buchs.
-
Ich habe keine bekommen
fatal
aber ich hatte bereits einen Commit im Zweig durchgeführt. Spielt das eine Rolle?– Kratylus
13. Juni 2013 um 20:32 Uhr
-
@Cratylus nein es spielt keine Rolle. Der Commit ist in Ihrem Repository sicher, und die
git push -u origin
kopierte es in das Remote-Repository.– Klas Melbourn
13. Juni 2013 um 20:35 Uhr
-
Nein ich meine die Tatsache, dass ich keine bekommen habe
fatal
msg wie die, die Sie in der Antwort erwähnen. Hängt dieser Unterschied davon ab, dass ich etwas an den Zweig übergeben habe?– Kratylus
13. Juni 2013 um 20:36 Uhr
-
@Cratylus Ich weiß nicht, warum du das nicht bekommen hast
fatal
Botschaft. Ich würde vermuten, dass der Unterschied genau davon abhängt, welche Git-Implementierung Sie verwenden. Meine Ausgabe stammt von 1.8.1.msysgit.1, das unter Windows 8 ausgeführt wird.– Klas Melbourn
13. Juni 2013 um 20:38 Uhr
-
Ich habe die gleiche Version, aber auf Vista
– Kratylus
13. Juni 2013 um 20:40 Uhr
Fred Fu
Ich konnte so schnell keine Begründung von den ursprünglichen Entwicklern finden, aber ich kann Ihnen eine fundierte Vermutung geben, die auf ein paar Jahren Git-Erfahrung basiert.
Nein, nicht jede Branche will man nach außen tragen. Es könnte ein privates Experiment darstellen.
Außerdem, wo sollte git push
alle Zweige senden? Git kann mit mehreren Remotes arbeiten und Sie möchten möglicherweise unterschiedliche Sätze von Branches auf jedem haben. Beispielsweise kann ein GitHub-Repo eines zentralen Projekts Release-Zweige haben; ein GitHub-Fork kann Themenzweige zur Überprüfung haben; und ein lokaler Git-Server kann Zweige haben, die lokale Konfigurationen enthalten. Wenn git push
würde alle Verzweigungen auf die Fernbedienung schieben, die die aktuelle Verzweigung verfolgt, wäre diese Art von Schema leicht zu vermasseln.
HEAD ist die Abkürzung für Current Branch, also funktioniert git push -u origin HEAD. Um diese Eingabe jetzt zu vermeiden, wenn ich Alias verwende:
git config –global alias.pp ‘push -u origin HEAD’
Danach kann ich jedes Mal, wenn ich den über git -b branch erstellten Zweig pushen möchte, ihn folgendermaßen pushen:
git pp
Hoffe, das spart Zeit für jemanden!
Thomas Fritsch
Zuerst prüfen
Schritt 1: git remote -v
//Wenn gefunden, git initialisieren, dann Schritt 2 entfernen oder überspringen
Schritt 2: git remote rm origin
//Dann konfigurieren Sie Ihre E-Mail-Adresse global git
Schritt 3: git config --global user.email "[email protected]"
Schritt 4: git initial
Schritt-5: git commit -m "Initial Project"
//Wenn Sie bereits ein Projekt-Repo hinzugefügt haben, überspringen Sie Schritt-6
Schritt-6: git remote add origin %repo link from bitbucket.org%
Schritt-7: git push -u origin master
Markus Birbeck
Ich habe gerade eine weitere Permutation dieses Problems erlebt.
Ich hatte einen Zweig namens feat/XYZ-1234-some-description
weil ich am Jira-Problem 1234 gearbeitet habe. Während der Arbeit habe ich ein neues Jira-Problem erstellt, um ein kleineres Stück Arbeit zu verfolgen, und als ich zum Pushen kam, entschied ich mich, zu einem Branch-Namen mit dieser neuen Issue-Nummer zu pushen in:
git push -u origin feat/XYZ-5678-a-different-description # failed
Dies gab mir den Fehler, der in diesem SO-Thread diskutiert wird. Aber da versuchte ich, einen zu schieben unterschiedlich Filialname aus meiner aktuellen Filiale, mein Problem war anders als das hier beschriebene. Am Ende habe ich meinen lokalen Zweig umbenannt, bevor ich ihn pushen konnte:
git branch -m feat/XYZ-1234-some-description feat/XYZ-5678-a-different-description
git push -u origin feat/XYZ-5678-a-different-description # now works
Nachdem ich ein bisschen mehr herumgelesen hatte, wurde mir klar, dass ich eine hätte setzen können src
auf der
git push
entweder zum aktuellen Zweignamen oder einfach nur HEAD
Falls zutreffend:
git push -u origin feat/XYZ-1234-some-description:feat/XYZ-5678-a-different-description # also works
Beachten Sie, dass dies konfigurierbar ist (setting
push.default
sehenman git-config
). Wenn Sie tungit config --add push.default current
danngit push
erstellt bei Bedarf automatisch den Zweig im Remote-Repository. Warum dies nicht der Standard ist, wird in den Antworten erklärt.– schleske
13. Juni 2013 um 21:31 Uhr
@sleske Ich stimme zu. Für die anderen Policen ‘
current
‘ und ‘upstream
‘, siehe meine ältere Antwort stackoverflow.com/a/13751847/6309.– VonC
13. Juni 2013 um 21:46 Uhr
Warum keine Antwort akzeptieren?
– See9m
10. Oktober 2014 um 7:57 Uhr