git push

Der Befehl git push wird verwendet, um Inhalte aus einem lokalen Repository in ein Remote-Repository hochzuladen. Per Push überträgst du Commits aus deinem lokalen Repository in ein Remote-Repository. Der Befehl ist das Gegenstück zu git fetch: Ein Fetch importiert Commits in lokale Branches, ein Push exportiert Commits in Remote-Branches. Remote-Branches werden mit dem Befehl git remote konfiguriert. Da beim Pushen das Risiko besteht, Änderungen zu überschreiben, solltest du dabei Vorsicht walten lassen. Wir gehen unten näher auf diese Gefahr ein.

"git push" – Verwendung

git push <remote> <branch>

Mit diesem Befehl pushst du den angegebenen Branch an das in "" angegebene Remote-Repository, zusammen mit allen notwendigen Commits und internen Objekten. Dadurch wird im Ziel-Repository ein lokaler Branch erstellt. Damit keine Commits überschrieben werden, blockiert Git Push-Vorgänge, durch die ein Nicht-Fast-Forward-Merge im Ziel-Repository angestoßen werden würde.

git push <remote> --force

Dieser Befehl ist identisch mit dem oben beschriebenen, erzwingt den Push jedoch auch dann, wenn durch ihn ein Nicht-Fast-Forward-Merge angestoßen werden würde. Verwende das Flag --force nur, wenn du dir absolut sicher bist.

git push <remote> --all

Verschiebt alle lokalen Branches zum angegebenen Remote-Branch

git push <remote> --tags

Tags werden nicht automatisch eingeschlossen, wenn du einen Branch pushst oder die Option --all verwendest. Das Flag --tags sendet alle deine lokalen Tags an das Remote-Repository.

"git push" – Erläuterung

git push wird üblicherweise verwendet, um lokale Änderungen in einem zentralen Repository zu veröffentlichen und hochzuladen. Nach dem Vornehmen von Änderungen an einem lokalen Repository werden die Änderungen per Push für Teammitglieder an anderen Standorten freigegeben.

Das Diagramm oben verdeutlicht, was passiert, wenn dein lokaler master aktueller ist als der master des zentralen Repositorys und du Änderungen per git push origin master veröffentlichst. Du siehst: git push arbeitet im Grunde genommen genauso wie git merge master im Remote-Repository.

"git push" und Synchronisierung

git push ist nur eine von vielen Komponenten im Gesamtprozess der Git-"Synchronisierung". Die Synchronisierungsbefehle wirken sich auf Remote-Branches aus, die mit dem Befehl git remote konfiguriert werden. git push kann als Befehl zum "Hochladen" betrachtet werden, git fetch und git pull dagegen als Befehle zum "Herunterladen". Nachdem die Changesets per Download oder Upload verschoben wurden, können die Änderungen am Ziel mit git merge integriert werden.

Pushen an Bare-Repositorys

Bei einem häufig genutzten, modernen Git-Verfahren fungiert ein remote gehostetes --bare-Repository als zentrales Ursprungs-Repository. Dieses Ursprungs-Repository wird oft extern von einem vertrauenswürdigen Drittanbieter wie Bitbucket gehostet. Da beim Pushen die Remote-Branch-Struktur manipuliert wird, ist es am sichersten und gängigsten, an Repositorys zu pushen, die mit dem Flag --bare erstellt wurden. Bare-Repositorys haben kein Arbeitsverzeichnis, sodass ein Push keine in Bearbeitung befindlichen Arbeitsverzeichnisinhalte verändern kann. Weitere Informationen zum Erstellen von Bare-Repositorys findest du im Abschnitt zu git init.

Verschieben erzwingen

Git lehnt Push-Anfragen ab, die einen Nicht-Fast-Forward-Merge anstoßen würden. Dadurch wird verhindert, dass der Verlauf des zentralen Repositorys überschrieben wird. Wenn also der Verlauf des Remote-Repositorys von deinem eigenen Verlauf abweicht, musst du den Remote-Branch pullen und mit deinem lokalen Branch mergen. Anschließend kannst du den Push erneut versuchen. Dieser Prozess ähnelt der SVN-basierten Synchronisierung mit einem zentralen Repository per svn update vor dem Commit eines Changesets.

Das Flag --force setzt dieses Verhalten außer Kraft und bewirkt, dass der Branch des Remote-Repositorys an deinen lokalen Branch angeglichen wird. Dabei werden sämtliche Upstream-Änderungen gelöscht, die seit dem letzten Pull vorgenommen wurden. Du solltest einen Push nur dann auf diese Weise erzwingen, wenn Commits, die du gerade veröffentlicht hast, fehlerhaft waren und du sie mit git commit --amend oder einem interaktiven Rebase korrigiert hast. Selbst dann musst du jedoch vor der Verwendung der Option --force unbedingt sicherstellen, dass keine deiner Teamkollegen die betreffenden Commits bereits gepullt haben.

Beispiele

Standard-Git-Push

Im folgenden Beispiel beschreiben wir eine der Standardmethoden zum Veröffentlichen lokaler Codebeiträge im zentralen Repository. Zunächst wird per Fetch eine Kopie des lokalen Masters aus dem zentralen Repository abgerufen und per Rebase mit deinen Änderungen zusammengeführt. Damit ist sichergestellt, dass dein lokaler Master aktuell ist. Darüber hinaus ist ein solcher interaktiver Rebase eine gute Gelegenheit, deine Commits vor der Veröffentlichung zu bereinigen. Im nächsten Schritt werden alle Commits aus deinem lokalen Master mit dem Befehl git push an das zentrale Repository gesendet.

git checkout master
git fetch origin master
git rebase -i origin/master
# Squash commits, fix up commit messages etc.
git push origin master

Da wir bereits dafür gesorgt haben, dass der lokale Master auf dem neuesten Stand ist, sollte hierdurch ein Fast-Forward-Merge angestoßen werden, und git push sollte keine der oben beschriebenen Nicht-Fast-Forward-Probleme melden.

Erzwingen von korrigierten Pushes

Beim Befehl git commit kannst du die Option --amend nutzen, um den vorherigen Commit zu aktualisieren. Oft wird ein Commit auf diese Weise korrigiert, um die Commit-Nachricht zu aktualisieren oder neue Änderungen hinzuzufügen. Wenn ein Commit korrigiert wurde, schlägt git push fehl, weil Git den korrigierten Commit und den Remote-Commit als unterschiedliche Inhalte betrachtet. Daher musst du das Pushen korrigierter Commits mit der Option --force erzwingen.

# make changes to a repo and git add
git commit --amend
# update the existing commit message
git push --force origin master

Im Beispiel oben gehen wir davon aus, dass die Ausführung für ein bestehendes Repository mit Commit-Verlauf erfolgt. Mit git commit --amend wird der vorherige Commit aktualisiert. Das Pushen des korrigierten Commits wird dann mit der Option --force erzwungen.

Löschen eines Remote-Branchs oder Tags

Manchmal müssen Branches aus buchhalterischen oder organisatorischen Gründen bereinigt werden. Um einen Branch vollständig zu löschen, muss er lokal und auch remote gelöscht werden.

git branch -D branch_name
git push origin :branch_name

Auf die oben gezeigte Weise wird der Remote-Branch mit dem Namen "branch_name" gelöscht. Durch Übergeben eines Branch-Namens mit einem vorangestellten Doppelpunkt an git push wird der Remote-Branch gelöscht.