git push
Auf dieser Seite finden Sie nützliche Informationen über den Befehl git push, seine Verwendung, die häufigsten Optionen und wichtige Hinweise dazu.
Diese Seite erklärt, was git push tut, die Syntax und nützlichsten Optionen, wie das Pushen gegen bare und non-bare Repositories funktioniert, wie man einen Upstream-Branch festlegt, wie man sicher force-pushed und wie man einen Remote-Branch löscht. Die Beispiele verwenden genaue Git-Befehle und Ausgaben, sodass Sie ihnen folgen können.
Definition
Der Befehl git push lädt Commits aus Ihrem lokalen Repository in ein Remote-Repository hoch. Pushen ist das Gegenteil von Fetchen: Während git fetch Commits in Ihre lokalen Tracking-Branches importiert, exportiert git push Ihre lokalen Commits in die Remote-Branches, damit Mitarbeiter sie sehen können.
Die grundlegende Syntax lautet:
git push <remote> <branch><remote> ist der Name des Remote-Repositories (am häufigsten origin), und <branch> ist der lokale Branch, dessen Commits Sie veröffentlichen möchten.
Verwendung von git push
Der Befehl git push wird häufig verwendet, um lokale Änderungen in einem zentralen Repository zu veröffentlichen. Nachdem Sie Änderungen lokal committet haben, führen Sie git push aus, um sie mit dem Rest des Teams zu teilen. Es ist einer der Befehle, die am Syncing-Workflow beteiligt sind. Diese Befehle arbeiten mit den Remote-Branches, die mit dem Befehl git remote konfiguriert wurden: Commits werden mit git push hochgeladen und mit git fetch und git pull heruntergeladen. Nach dem Herunterladen integriert git merge die Änderungen in Ihren Arbeitsbranch.
Ein erfolgreicher Push gibt eine Zusammenfassung der übertragenen Daten aus. Zum Beispiel sieht das Pushen von zwei neuen Commits auf master so aus:
$ git push origin master
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Writing objects: 100% (6/6), 612 bytes | 612.00 KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To github.com:example/repo.git
a1b2c3d..e4f5g6h master -> masterDie Zeile a1b2c3d..e4f5g6h master -> master bestätigt, welche Commits übertragen wurden und dass Ihr lokaler master jetzt dem Remote-master entspricht.
Das folgende Diagramm zeigt den Verlauf des lokalen master über den master des zentralen Repositories hinaus und die Veröffentlichung dieser Änderungen durch Aufruf von git push origin master.
Häufige Optionen
git push <remote> <branch> | Pusht den angegebenen Branch zu <remote> mit den notwendigen Commits und erstellt dabei einen Remote-Branch im Ziel-Repository. |
|---|---|
git push <remote> --force | Erzwingt den Push, auch wenn er zu einem Non-Fast-Forward-Update führt. Stellen Sie sicher, dass niemand die Commits gezogen hat, bevor Sie die Option --force verwenden. |
git push <remote> --all | Pusht alle lokalen Branches in das Remote-Repository. |
git push <remote> --tags | Pusht die Tags der lokalen Branches in das Remote-Repository. Die Option --all pusht keine Tags. |
git push -u <remote> <branch> | Pusht den Branch und speichert ihn als Upstream-(Tracking-)Branch, sodass zukünftige git push- und git pull-Befehle ohne Argumente ausgeführt werden können. |
git push <remote> --force-with-lease | Führt einen Force-Push nur durch, wenn der Remote-Branch sich seit dem letzten Fetch nicht verändert hat — eine sicherere Alternative zu --force. |
git push <remote> --dry-run | Zeigt an, was gepusht werden würde, ohne tatsächlich etwas an das Remote-Repository zu senden. |
Pushen in bare Repositories
Ein bare Repository ist eines, das mit dem Flag --bare erstellt wurde (git init --bare oder git clone --bare). Es hat kein Arbeitsverzeichnis, sodass niemand direkt darin Dateien bearbeiten oder committen kann. Dies macht es sicher zum Pushen, weshalb zentrale/gemeinsame Repositories (die auf einem Server oder einem Dienst wie GitHub gehostet werden) bare sind. Das Pushen in ein non-bare Repository, dessen Arbeitsbranch ausgecheckt ist, kann zu Konflikten mit dem Arbeitsbaum dieses Branches führen, weshalb Git solche Pushes standardmäßig ablehnt.
# create a shared central repository
git init --bare central.gitWas passiert, wenn ein Push abgelehnt wird
Git verweigert Ihren Push, wenn der Remote-Branch Commits enthält, die Sie lokal nicht haben — ein Non-Fast-Forward-Update. Dies bedeutet normalerweise, dass ein Teammitglied zuerst gepusht hat. Der Fehler sieht so aus:
$ git push origin master
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'github.com:example/repo.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.Die Lösung besteht darin, zuerst die Remote-Arbeit einzuholen und dann erneut zu pushen:
git pull origin master # fetch + merge (or use --rebase)
git push origin masterGreifen Sie nur auf --force zurück, wenn Sie die Remote-History absichtlich überschreiben möchten (siehe unten) — nicht um diese Sicherheitsprüfung bei gemeinsam genutzten Branches zu umgehen.
Force-Push
Das Flag --force überschreibt den Remote-Branch mit Ihrem lokalen Branch und verwirft alle Upstream-Commits, die nicht gepullt wurden. Verwenden Sie es nur, wenn Sie die History absichtlich neu geschrieben haben — zum Beispiel nach git commit --amend oder einem interaktiven git rebase — und Sie sicher sind, dass niemand anderes auf den Commits aufgebaut hat, die Sie ersetzen. Wenn ein Commit geändert oder rebasiert wird, ändert sich sein Hash, sodass Git ihn und den Remote-Commit als divergierten Inhalt behandelt und einen normalen Push ablehnt; --force ist erforderlich, um den neu geschriebenen Commit zu veröffentlichen.
Bevorzugen Sie für gemeinsam genutzte Branches --force-with-lease (weiter unten behandelt): Es verweigert das Überschreiben von Arbeit, die das Remote-Repository nach Ihrem letzten Fetch erhalten hat, sodass Sie die Commits eines Teammitglieds nicht versehentlich löschen können.
git push --force
# make changes to a repo and git add
git commit --amend
# update the existing commit message
git push --force origin masterEinen Remote-Branch löschen
Hier ist ein Beispiel für das Löschen des Remote-Branches. Der branch_name mit einem vorangestellten Doppelpunkt bei git push löscht den Remote-Branch:
Remote-Branch löschen, git push
git branch -D branch_name
git push origin :branch_nameDer Befehl git push origin :branch_name löscht den angegebenen Branch (branch_name) aus dem Remote-Repository (origin), indem eine leere Referenz darauf gepusht wird.
Wie es funktioniert
git push: Änderungen aus Ihrem lokalen Git-Repository in ein Remote-Repository pushenorigin: der Name des Remote-Repositories:branch_name: eine Refspec, die eine leere Referenz darstellt und den angegebenen Branch effektiv aus dem Remote-Repository löscht
Wenn Sie also git push origin :branch_name ausführen, löscht Git den Branch branch_name aus dem Remote-Repository origin.
Beachten Sie, dass dieser Befehl gefährlich sein kann, wenn er falsch verwendet wird, da er den Branch ohne Bestätigung oder Möglichkeit zur Wiederherstellung löscht. Stellen Sie sicher, dass Sie den Branch-Namen doppelt prüfen und dass Sie ihn wirklich löschen möchten, bevor Sie den Befehl ausführen.
Das Flag -u beim ersten Push eines Branches verwenden
Wenn Sie einen lokalen Branch haben und ihn zum ersten Mal in das Remote-Repository pushen möchten, sollten Sie angeben, welchen Branch des Remote-Repositories Sie meinen. In Git wird das Flag -u mit dem Befehl git push verwendet, um den Upstream-Branch für den aktuellen Branch festzulegen. Wenn Sie das Flag -u verwenden, erstellt Git eine Verknüpfung zwischen Ihrem lokalen Branch und dem Remote-Branch. Diese Verknüpfung ist nützlich, um die Befehle git pull und git push in Zukunft zu vereinfachen, da Git sich merkt, welcher Remote-Branch Ihrem lokalen Branch entspricht.
Das Flag -u ist die Kurzform von --set-upstream. Wenn Sie dieses Flag verwenden, sieht es typischerweise so aus:
Das Flag -u beim ersten Push eines Branches verwenden
git push -u origin your-branch-nameDanach verfolgt Ihr lokaler Branch origin/your-branch-name. Von da an können Sie git push und git pull ohne zusätzliche Argumente ausführen, während Sie sich auf diesem Branch befinden, und git status zeigt an, wie viele Commits Sie dem Remote voraus oder hinterher sind. Weitere Informationen zu lokalen und Remote-Tracking-Branches finden Sie unter git branch.
Beispiele für häufig verwendete Flags
Hier sind kurze Beispiele der nützlichsten git push-Flags.
-f (force)
git push -f origin masterForce-pushed den lokalen master-Branch zu origin und überschreibt alle Commits auf dem Remote-master, die Sie lokal nicht haben. -f ist die Kurzform von --force. Verwenden Sie es mit Vorsicht — es kann Commits anderer Personen löschen, wenn sie am selben Branch arbeiten.
--tags
git push origin --tagsPusht alle Ihre lokalen Tags zu origin. Tags kennzeichnen wichtige Punkte in der History, wie Releases oder Meilensteine. Ein normaler git push überträgt keine Tags, daher ist dieses Flag (oder das Pushen eines bestimmten Tags mit git push origin <tagname>) die Art und Weise, wie Sie sie veröffentlichen. Weitere Informationen zum Erstellen von Tags finden Sie unter git tag.
--all
git push origin --allPusht alle lokalen Branches in einem Befehl zu origin. Beachten Sie, dass --all keine Tags enthält — kombinieren Sie es mit einem separaten --tags-Push, wenn Sie beides benötigen.
--dry-run
git push --dry-run origin masterSimuliert den Push und meldet, was gesendet werden würde, ohne tatsächlich etwas zu übertragen. Nützlich, um genau zu bestätigen, welche Commits und Refs ein Push aktualisieren wird, bevor Sie ihn tatsächlich ausführen.
--force-with-lease
git push --force-with-lease origin masterForce-pushed master zu origin nur dann, wenn der Remote-Branch noch auf denselben Stand zeigt wie beim letzten Fetch. Wenn jemand in der Zwischenzeit gepusht hat, bricht der Befehl ab, anstatt dessen Arbeit zu überschreiben. Dies ist die sicherere Alternative zu -f/--force.