Warum muss ich explizit einen neuen Zweig pushen?

Lesezeit: 8 Minuten

Warum muss ich explizit einen neuen Zweig pushen
Kratylos

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?

  • Beachten Sie, dass dies konfigurierbar ist (setting push.defaultsehen man git-config). Wenn Sie tun git config --add push.default currentdann git 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

Warum muss ich explizit einen neuen Zweig pushen
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 masterreicht 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 einfache git 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 oder git 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

1646878094 732 Warum muss ich explizit einen neuen Zweig pushen
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


Warum muss ich explizit einen neuen Zweig pushen
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

1646878095 911 Warum muss ich explizit einen neuen Zweig pushen
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!

1646878095 6 Warum muss ich explizit einen neuen Zweig pushen
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

1646878096 872 Warum muss ich explizit einen neuen Zweig pushen
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 pushentweder 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

985610cookie-checkWarum muss ich explizit einen neuen Zweig pushen?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy