Pushen — was es ist, wie git push funktioniert und wann es nötig ist

Was ist ein Push in Git

Git push ist ein Befehl, der Commits von einem lokalen Repository zu einem entfernten überträgt. Im Gegensatz zu einem Commit, der Änderungen nur auf dem lokalen Rechner des Entwicklers speichert, veröffentlicht ein Push diese Änderungen für das gesamte Team. Push ist ein obligatorischer Schritt vor der Erstellung eines Pull Requests und des Deployments.

Die Architektur von Git geht davon aus, dass jeder Entwickler in seinem eigenen lokalen Repository arbeitet. Commits werden lokal erstellt und sammeln sich an, bis der Entwickler beschließt, sie zu pushen. Dies bietet Freiheit: Sie können viele lokale Commits machen, experimentieren und die Geschichte umschreiben, ohne Kollegen zu beeinträchtigen.

# In das entfernte Origin, main-Branch pushen
git push origin main

# Aktuellen Branch mit Upstream ins entfernte Repository pushen
git push -u origin feature/new-dashboard

# Alle Branches mit übereinstimmenden Namen pushen
git push --all origin

# Force Push mit Lease (sicherer Force Push)
git push --force-with-lease

Nach einem Push aktualisiert das entfernte Repository die Refs (Branch-Referenzen), sodass sie auf die neuen Commits zeigen. Andere Entwickler können diese Änderungen über git pull oder git fetch abrufen. Dieser Austausch von Commits bildet die Grundlage der kollaborativen Entwicklung.

Wie git push funktioniert

Der Befehl git push vergleicht lokale und entfernte Branches und überträgt nur die fehlenden Commits. Git sendet nicht alle Dateien erneut — es überträgt nur das Delta, was den Push selbst bei großen Repositorys schnell macht. Git-Protokoll verwendet Smart Transfer, der die Menge der übertragenen Daten minimiert.

Wenn der entfernte Branch Commits enthält, die lokal nicht vorhanden sind, wird der Push abgelehnt. Dies ist ein Schutzmechanismus, der den Verlust von Änderungen verhindert. In dieser Situation muss der Entwickler zuerst git pull ausführen, die Änderungen zusammenführen und dann erneut pushen. Eine Alternative ist der Force Push, der den entfernten Branch überschreibt, aber mit Vorsicht verwendet werden muss.

Das Verständnis von entfernten Repositorys ist der Schlüssel zum richtigen Pushen. Normalerweise ist origin der Standardname des entfernten Repositorys. Der Befehl git remote -v zeigt die Liste der entfernten Repositorys und ihre URLs. Sie können mehrere Remotes hinzufügen (z. B. origin für das Haupt-Repository und upstream für einen Fork).

Wann soll man Änderungen pushen

Die Hauptregel: Pushen Sie nach jeder logisch abgeschlossenen Arbeitsphase. Wenn ein Entwickler eine Aufgabe oder einen Teil davon abgeschlossen hat — ist es Zeit zu pushen. Es wird jedoch nicht empfohlen, unvollendete Arbeit zu pushen, die den Build beschädigt. Build nicht beschädigt ist die Mindestanforderung für das Pushen in einen beliebigen Branch.

In der Teamarbeit wird folgender Rhythmus angenommen: morgens — git pull, um die Änderungen der Kollegen zu erhalten, tagsüber — mehrere Commits und ein oder zwei Pushes, abends — ein abschließender Push aller erledigten Aufgaben. Je häufiger ein Entwickler pusht, desto geringer ist das Risiko von Merge-Konflikten und desto transparenter ist der Arbeitsfortschritt.

• Nach Abschluss einer Aufgabe — committen und die endgültige Lösung in den Feature-Branch pushen
• Vor dem Feierabend — unvollendete Arbeit in einen Feature-Branch pushen (nicht in main!)
• Vor der Erstellung eines PR — sicherstellen, dass alle Commits gepusht und für die Review verfügbar sind
• Nach Rebase — mit --force-with-lease in den eigenen Feature-Branch pushen

Regeln für sicheren Push

Sicherer Push ist eine Reihe von Regeln, die Datenverlust und Konflikte im Team verhindern. Die erste und wichtigste Regel: Pushen Sie niemals direkt in den main- oder master-Branch, wenn das Projekt kein direktes Deployment konfiguriert hat. In modernen Teams wird der Schutz des main-Branch auf der Ebene des GitHub-Branch-Schutzes konfiguriert.

Die zweite Regel: Synchronisieren Sie vor dem Push mit dem entfernten Branch. Führen Sie git pull --rebase aus, um Merge-Commits beim Zusammenführen zu vermeiden. Dies vereinfacht die Historie und macht sie linear. Wenn ein Push abgelehnt wird — verwenden Sie keinen einfachen Force Push, sondern finden Sie zunächst heraus, welche Commits auf dem entfernten Branch aufgetaucht sind.

Die dritte Regel: Richten Sie Pre-Push-Hooks ein, die vor dem Senden automatisch Tests und Linter ausführen. Wenn Tests fehlschlagen — wird der Push blockiert. Solche Hooks werden über Husky oder Git-Hooks (pre-push-Datei in .git/hooks) konfiguriert.

Die vierte Regel: Pushen Sie keine großen Binärdateien. Git ist nicht für die Speicherung binärer Artefakte ausgelegt — sie blähen das Repository auf und verlangsamen Operationen. Für große Dateien verwenden Sie Git LFS (Large File Storage). Wenn eine Binärdatei bereits gepusht wurde und in der Historie ist, muss sie über git filter-branch entfernt werden.

Was tun, wenn der Push fehlschlägt

Der häufigste Grund für einen fehlgeschlagenen Push ist, dass der entfernte Branch Commits enthält, die lokal nicht vorhanden sind. Dies passiert, wenn ein anderer Entwickler seine Änderungen in denselben Branch gepusht hat. Lösung: git pull ausführen, eventuelle Konflikte lösen und erneut pushen.

# Push abgelehnt — zuerst fetch und rebase ausführen
git fetch origin
git rebase origin/main
# Konflikte lösen, dann:
git push --force-with-lease

# Oder einfach die entfernten Änderungen zusammenführen
git pull origin main
git push

Der zweite Grund — fehlende Schreibberechtigungen für den Branch. Wenn der main-Branch durch Branch-Protection-Regeln geschützt ist, sind direkte Pushes verboten. Lösung: in einen Feature-Branch pushen und einen Pull Request erstellen. Die Schutzeinstellungen werden normalerweise über GitHub-Einstellungen oder GitLab Protected Branches verwaltet.

Der dritte Grund — Authentifizierungsprobleme. Veraltete Anmeldeinformationen, Wechsel zu SSH oder geändertes Personal Access Token. Lösung: die Remote-URL (git remote -v) überprüfen und die Anmeldeinformationen aktualisieren. Seit 2021 hat GitHub die Passwortauthentifizierung für HTTPS eingestellt — verwenden Sie ein persönliches Token oder einen SSH-Schlüssel.