git push

Teilen & Aktualisieren

Remote-Refs samt zugehöriger Objekte aktualisieren

Der Befehl 'git push' lädt Inhalte aus dem lokalen Repository in ein Remote-Repository hoch. Er überträgt Commits und Branch-Updates (und Tags, wenn du sie mit --tags oder --follow-tags anforderst) von deinem lokalen Repo zu einem Remote, sodass deine Änderungen für andere verfügbar werden. Mit Push teilst du deine Arbeit – nach dem lokalen Commit pushst du, um dich mit dem Team zu synchronisieren. Standardmäßig (push.default=simple) aktualisiert git push nur den Upstream-Branch des aktuellen Branches, der existieren und gleich heißen muss, und nur bei einem Fast-Forward (der Remote-Branch ist also ein Vorfahre deines lokalen Branches).

Syntax

git push [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [-f | --force] [-d | --delete] [--prune] [-q | --quiet] [-v | --verbose] [-u | --set-upstream] [-o <string>] [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]] [--no-verify] [<repository> [<refspec>...]]
[ ] optional| oder<arg> Platzhalter... wiederholbar--flag Option

Optionen

Klicke auf eine Option, um sie aufzuklappen

Einsteiger (7)

Das Remote-Repository, zu dem gepusht wird. Ohne Angabe nutzt Git das für den aktuellen Branch konfigurierte Remote (seinen Upstream), ersatzweise 'origin'. Es kann eine URL oder der Name eines Remotes sein.

Bei BedarfNennt das Ziel-Remote ausdrücklich; sonst wird das Remote des Upstreams genutzt

Beispiel

git push origin main

Für jeden aktuellen oder erfolgreich gepushten Branch eine Upstream-(Tracking-)Referenz hinzufügen. So kannst du 'git push' und 'git pull' für diesen Branch künftig ohne Argumente nutzen.

EmpfohlenEinmal bei einem neuen Branch setzen; danach funktionieren einfaches push und pull

Beispiel

git push -u origin feature-branch

Alle Branches zum Remote pushen: Jeder Branch unter refs/heads/ geht zum gleichnamigen Branch auf dem Remote. Seit Git 2.41 auch als --branches schreibbar. Tags sind nicht enthalten, und es lässt sich nicht mit anderen Refspecs kombinieren.

Bei BedarfPusht jeden lokalen Branch, auch Experimente, die privat bleiben sollten

Beispiel

git push --all origin

Zusätzlich zu den Refspecs auf der Befehlszeile alle Refs unter refs/tags pushen. Alle lokalen Tags werden zum Remote gepusht.

Bei BedarfPusht jeden lokalen Tag, auch verirrte oder leichtgewichtige

Beispiel

git push --tags origin

Alles tun außer die Updates tatsächlich zu senden. Zeigt, was gepusht würde, ohne etwas am Remote zu ändern.

Bei BedarfZeigt vorab, was gepusht würde; der pre-push-Hook läuft trotzdem

Beispiel

git push --dry-run origin main

Ausführlich arbeiten. Liefert zusätzliche Ausgaben dazu, was gepusht wird, und zum Fortschritt der Operation.

Bei BedarfMehr Details beim Debuggen eines Pushs

Beispiel

git push -v origin main

Jede Ausgabe unterdrücken, auch die Liste aktualisierter Refs, außer es tritt ein Fehler auf. Fortschritt wird nicht angezeigt.

Bei BedarfFür Skripte; Ausgabe nur bei Fehlern

Beispiel

git push -q origin main

Fortgeschritten (6)

Alle angegebenen Refs werden aus dem Remote-Repository gelöscht. Entspricht einem Doppelpunkt vor jeder Ref (z. B. :branch-name).

Bei BedarfEntfernt einen Remote-Branch nach dem Mergen; auf dem Remote nicht rückgängig zu machen

Beispiel

git push --delete origin feature-old

Normalerweise weigert sich der Befehl, eine Remote-Ref zu aktualisieren, die kein Vorfahre der überschreibenden lokalen Ref ist. Diese Option schaltet die Prüfungen ab und erlaubt Non-Fast-Forward-Updates. Das Remote-Repository kann dabei Commits verlieren; mit Vorsicht nutzen.

Nicht empfohlenÜberschreibt das Remote blind – nutze stattdessen --force-with-lease

Beispiel

git push --force origin feature-branch

Eine sicherere Alternative zu --force. Diese Option erlaubt einen Force-Push, prüft aber vorher, dass die Remote-Ref seit deinem letzten Fetch nicht von jemand anderem aktualisiert wurde. Hat sich das Remote geändert, wird der Push abgelehnt – so überschreibst du nicht versehentlich fremde Arbeit. Verglichen wird mit deinem Remote-Tracking-Branch, daher setzt ein Fetch (auch im Hintergrund) ohne Integration die Prüfung zurück; kombiniere mit --force-if-includes.

EmpfohlenDer sichere Weg, umgeschriebene Historie zu pushen; verweigert, wenn sich das Remote bewegt hat

Beispiel

git push --force-with-lease origin feature-branch

Die angegebene Zeichenkette an den Server senden, der sie an die Hooks pre-receive und post-receive weitergibt. Mehrfach angebbar für mehrere Optionen. Nützlich, um CI/CD-Verhalten auszulösen oder Metadaten zu übergeben.

Bei BedarfSendet serverspezifische Optionen (z. B. CI-Hinweise), die dein Hoster versteht

Beispiel

git push -o ci.skip origin main

Remote-Branches entfernen, die kein lokales Gegenstück haben. Gilt nur für Refs, die auf eine Wildcard-Refspec (oder --all) passen: Bei einem einfachen 'git push --prune origin' wird nichts gelöscht. Löscht Remote-Branches unwiderruflich, also vorher mit --dry-run prüfen.

Nicht empfohlenLöscht Remote-Branches, die lokal fehlen; ein einziger veralteter Klon kann die Arbeit von Kollegen löschen

Beispiel

git push --all --prune origin

Statt jede zu pushende Ref zu nennen, werden alle Refs unter refs/ (darunter refs/heads/, refs/remotes/ und refs/tags/) auf das Remote-Repository gespiegelt. Neu angelegte lokale Refs werden gepusht, lokal geänderte erzwungen aktualisiert und gelöschte entfernt. Im Ergebnis wird jede Ref force-gepusht und jede Remote-Ref gelöscht, die lokal nicht existiert.

Nicht empfohlenAktualisiert jede Ref auf dem Remote erzwungen und löscht sie; nur für Backups oder Migrationen

Beispiel

git push --mirror origin

Erfahren (11)

Den pre-push-Hook überspringen. Standardmäßig führt git push den pre-push-Hook aus, falls vorhanden. Diese Option umgeht die lokale Prüfung (Server-Hooks laufen weiter). Sparsam einsetzen, da pre-push-Hooks meist wichtige Prüfungen wie Tests durchsetzen.

Nicht empfohlenÜberspringt deine pre-push-Prüfungen; nur, wenn ein kaputter Hook den Push blockiert

Beispiel

git push --no-verify origin main

Die Push-Anfrage, die auf der Empfängerseite Refs aktualisiert, mit GPG signieren. So kann der Server die Identität der pushenden Person prüfen. Erfordert eingerichtete GPG-Schlüssel, und der Server muss signierte Pushes unterstützen – sonst scheitert der Push („the receiving end does not support --signed push“). Auch 'true', 'false' oder 'if-asked' (nur signieren, wenn der Server es unterstützt) sind möglich.

Bei BedarfSigniert den Push mit GPG; scheitert, außer der Server unterstützt signierte Pushes

Beispiel

git push --signed origin main

Wenn verfügbar, auf der Remote-Seite eine atomare Transaktion nutzen. Entweder werden alle Refs aktualisiert oder bei einem Fehler keine. Unterstützt der Server keine atomaren Pushes, scheitert der Push. Nützlich beim Pushen mehrerer voneinander abhängiger Branches.

Bei BedarfAlles oder nichts beim gemeinsamen Pushen mehrerer zusammengehöriger Refs

Beispiel

git push --atomic origin main develop

Alle Refs pushen, die auch ohne diese Option gepusht würden, und zusätzlich annotierte Tags in refs/tags, die auf dem Remote fehlen und auf Commits zeigen, die von den gepushten Refs erreichbar sind. Mit der Einstellung push.followTags als Standard festlegbar.

EmpfohlenPusht annotierte Release-Tags auf gepushten Commits und lässt leichtgewichtige aus

Beispiel

git push --follow-tags origin main

Diese Option ist eine Alternative zum Argument <repository>. Sind beide angegeben, hat das Befehlszeilenargument Vorrang. Nützlich in Skripten oder Konfigurationen, um das Ziel-Repository ausdrücklich anzugeben.

Bei BedarfSelten nötig; dasselbe wie das Repository-Argument anzugeben

Beispiel

git push --repo=origin main

Die Übertragung durch ein „Thin Pack“ optimieren, das Objekte als Deltas gegen Objekte außerhalb des Packs speichert, um weniger über das Netzwerk zu senden. Das ist das Standardverhalten.

Bei BedarfSchon der Standard; du musst es nie tippen

Beispiel

git push --thin origin main

Die Optimierung durch „Thin Packs“ abschalten. Sendet ein vollständiges Pack, ohne sich auf Objekte zu verlassen, die beim Empfänger existieren könnten. Kann beim Debuggen von Übertragungsproblemen helfen.

Bei BedarfNur zur Fehlersuche bei Pack-Übertragungen

Beispiel

git push --no-thin origin main

Die Fortschrittsanzeige auf dem Fehlerkanal erzwingen, auch wenn er nicht mit einem Terminal verbunden ist. Nützlich in Skripten, in denen du den Push-Fortschritt trotzdem sehen willst.

Bei BedarfErzwingt Fortschrittsausgabe in Logs oder CI, wo stderr kein Terminal ist

Beispiel

git push --progress origin main

Ein Update nur erzwingen, wenn die Spitze der Remote-Tracking-Ref lokal integriert wurde. Ein sichererer Force-Push, der sicherstellt, dass du neue Remote-Commits wirklich in deine Arbeit übernommen hast, bevor du sie überschreibst. Wirkt nur zusammen mit --force-with-lease (ohne ausdrücklichen Erwartungswert).

EmpfohlenErgänze --force-with-lease, damit ein Hintergrund-Fetch den Lease nicht aushebelt

Beispiel

git push --force-with-lease --force-if-includes origin feature

Maschinenlesbare Ausgabe erzeugen. Die Statuszeile jeder Ref ist tabulatorgetrennt und geht nach stdout statt stderr. Nützlich für Skripte, die Push-Ergebnisse auswerten.

Bei BedarfMaschinenlesbare Ergebnisse für Skripte

Beispiel

git push --porcelain origin main

Steuern, wie Submodule beim Push behandelt werden. Werte: 'check' (scheitert, wenn Submodul-Commits nicht gepusht sind), 'on-demand' (pusht Submodul-Commits bei Bedarf), 'only' (pusht nur Submodule), 'no' (keine Rekursion).

Bei BedarfStellt sicher, dass Submodul-Commits zuerst gepusht werden

Beispiel

git push --recurse-submodules=on-demand origin main

Die richtige Option wählen

Die Sicherheitsleiter für Force-Push

Wenn du die Remote-Historie überschreiben musst, wähle die sicherste Option, die für deine Lage funktioniert

BefehlRisikoPrüft RemoteWann es scheitertAnwendungsfall
git pushSicher✓ Nur Fast-ForwardWenn das Remote neue Commits hatNormaler Alltag
git push --force-with-lease --force-if-includesSicherstes Erzwingen✓ Remote-Spitze in lokaler HistorieWenn du die Remote-Änderungen nicht integriert hastNach einem Rebase, wenn andere gepusht haben könnten
git push --force-with-leaseSichereres Erzwingen✓ Remote seit dem Fetch unverändertWenn sich das Remote seit dem letzten Fetch geändert hatNach einem Rebase auf einem persönlichen Branch
git push --forceGefährlich✗ Überschreibt blindNie (außer der Server lehnt ab)Nur, wenn du dir sicher bist, oder allein auf dem Branch

Was gepusht wird

Den Umfang dessen steuern, was du zum Remote sendest

BefehlPushtMit TagsTypische Nutzung
git push origin mainEin Branch✗Einen bestimmten Branch pushen
git push -u origin branchEin Branch + setzt Tracking✗Erster Push eines neuen Branches
git push --allAlle Branches✗Alle lokalen Branches synchronisieren
git push --tagsNur Tags (keine Branches)✓ Alle TagsVersions-Tags pushen
git push --follow-tagsAktueller Branch✓ Nur erreichbare annotierteMit den passenden Release-Tags pushen
git push --mirrorAlles✓ AllesExakter Klon auf dem Remote (löscht Refs, die nur remote existieren)

Ausgabe und Rückmeldung

Ausführlichkeit und Ausgabeformat an deinen Bedarf anpassen

BefehlAusgabeumfangZeigt FortschrittMaschinenlesbarAm besten für
git pushStandardNur im Terminal✗Normale interaktive Nutzung
git push --verboseAusführlich✓✗Push-Probleme debuggen
git push --quietNur Fehler✗✗Skripte, CI-Pipelines
git push --progressStandard + erzwungener Fortschritt✓ Immer✗Skripte, die Fortschritt im Log brauchen
git push --porcelainStrukturiert✗✓ TabulatorgetrenntPush-Ergebnisse in Skripten auswerten

Sicherheit und Überprüfung

Prüfungen vor dem Push und Kontrolloptionen

BefehlFührt Hooks ausPrüftErzeugt CommitWann verwenden
git push✓ pre-pushRemote akzeptiertN/ANormaler Workflow
git push --dry-run✓ pre-pushWas passieren würde✗ Nur VorschauVor wichtigen Pushes
git push --atomic✓Alle Refs oder keineAlles oder nichtsMehrere Branches zusammen pushen
git push --no-verify✗ Überspringt lokales pre-push (Server-Hooks laufen weiter)Remote akzeptiertN/ANotfall, wenn Hooks dich blockieren
git push --signed✓GPG-SignaturKryptografisch signiertHochsichere Repos, Identität nachweisen

Remote- und Branch-Verwaltung

Optionen zum Verwalten von Remote-Refs und Branch-Beziehungen

BefehlAktionWirkt auf RemoteAnwendungsfall
git push -u origin branchPush + Upstream setzenFügt Branch hinzuErster Push, richtet Tracking ein
git push origin --delete branchRemote-Branch löschenEntfernt BranchGemergte Branches aufräumen
git push --pruneRemote-Branches löschen, die du lokal gelöscht hast (braucht --all oder eine Wildcard-Refspec)Entfernt BranchesLöschungen aufs Remote übertragen
git push --repo=<url>Zu einem bestimmten Remote pushenZiel-RemoteZu einer anderen Remote-URL pushen

Workflow-Beispiele

1
git remote add origin https://github.com/user/repo.git

Die URL des Remote-Repositorys hinzufügen

2
git push -u origin main

Den main-Branch pushen und ihn origin/main folgen lassen

1
git status

Prüfen, dass du auf dem richtigen Branch bist und Commits zum Pushen hast

2
git push

Zum verfolgten Upstream-Branch pushen

1
git checkout feature

Auf deinen Feature-Branch wechseln

2
git rebase main

Auf main rebasen (schreibt die Commit-Historie um)

3
git push --force-with-lease

Sicher force-pushen – scheitert, wenn jemand anderes gepusht hat

1
git checkout -b feature/new-login

Neuen Branch anlegen und dorthin wechseln

2
git add . && git commit -m "Add new login"

Änderungen machen und committen

3
git push -u origin feature/new-login

Pushen und Upstream-Tracking einrichten

1
git push origin --delete feature/old-branch

Den Remote-Branch löschen

2
git branch -d feature/old-branch

Auch den lokalen Branch löschen

1
git push --all origin

Alle Branches unter refs/heads/ pushen

2
git push --tags origin

Optional auch alle Tags pushen

Fehlerbehebung

! [rejected] main -> main (fetch first) / (non-fast-forward)

Ursache: Der Remote-Branch hat Commits, die dein lokaler Branch nicht hat. Jemand anderes hat Änderungen gepusht, oder du hast bereits gepushte Commits gerebast/geamendet.

Hole zuerst die Remote-Änderungen mit 'git pull --rebase' oder 'git pull --no-rebase', löse eventuelle Konflikte und pushe dann erneut. Erzwinge (am besten mit '--force-with-lease') nur, wenn du sicher bist, dass niemand sonst den Branch nutzt.

git pull --rebase && git push

git@github.com: Permission denied (publickey)

Ursache: Die SSH-Anmeldung ist gescheitert: Kein Schlüssel ist geladen, oder dein öffentlicher Schlüssel ist nicht in deinem Konto hinterlegt. (Fehlende Schreibrechte führen zu einem anderen Fehler, „Permission to ... denied“.)

Prüfe, ob dein SSH-Schlüssel in deinem GitHub-/GitLab-Konto hinterlegt ist. Teste mit 'ssh -T git@github.com'. Bei HTTPS stelle sicher, dass du die richtigen Zugangsdaten nutzt.

ssh -T git@github.com

fatal: No configured push destination

Ursache: Das Repository hat überhaupt kein Remote konfiguriert. (Gibt es ein Remote, aber der Branch hat keinen Upstream, erscheint stattdessen „The current branch ... has no upstream branch“.)

Füge mit 'git remote add origin <url>' ein Remote hinzu und pushe dann mit gesetztem Upstream per 'git push -u origin <branch>'.

git push -u origin main

Your branch is behind 'origin/main'

Ursache: Der Remote-Branch hat neuere Commits als dein lokaler Branch. Du musst diese Änderungen integrieren, bevor du pushst.

Hole die Remote-Änderungen und merge oder rebase sie vor dem Pushen in deinen lokalen Branch.

git pull origin main && git push

refusing to update checked out branch

Ursache: Du versuchst, in ein Nicht-Bare-Repository zu pushen, in dem dieser Branch gerade ausgecheckt ist. Das könnte dessen Arbeitsverzeichnis inkonsistent machen.

Pushe in ein Bare-Repository oder lass den Empfänger zuerst einen anderen Branch auschecken. Das passiert meist bei eigenen Servern, nicht bei GitHub/GitLab.

git config receive.denyCurrentBranch updateInstead

error: failed to push some refs to '<remote-url>'

Ursache: Allgemeiner Fehler mit mehreren möglichen Ursachen: Non-Fast-Forward-Updates, fehlgeschlagene Hooks oder Rechteprobleme. Sieh dir die ausführliche Fehlermeldung über dieser Zeile an.

Lies die vollständige Fehlerausgabe. Meist ist es ein Non-Fast-Forward-Problem (erst pullen) oder ein fehlgeschlagener pre-push-Hook (behebe, was der Hook meldet).

git pull --rebase && git push

pre-push-Hook fehlgeschlagen

Ursache: Ein pre-push-Hook (Tests, Linting usw.) hat Probleme gefunden und den Push blockiert.

Behebe die vom Hook gemeldeten Probleme. Umgehe ihn mit '--no-verify' nur, wenn es wirklich nötig ist und du die Folgen verstehst.

git push --no-verify

remote: Repository not found

Ursache: Die Repository-URL ist falsch, das Repository wurde gelöscht oder umbenannt, oder du hast keinen Zugriff.

Prüfe die Repository-URL mit 'git remote -v'. Stelle sicher, dass das Repository existiert und du Zugriff hast. Passe die URL bei Bedarf an.

git remote set-url origin https://github.com/user/correct-repo.git

Tipps & Stolperfallen

Best Practices

  • ✓Immer vor dem Push pullen: Führe vor dem Pushen 'git pull' aus (oder 'git fetch' mit anschließendem Merge oder Rebase), damit du die neuesten Remote-Änderungen hast und abgelehnte Pushes vermeidest.
  • ✓--force-with-lease statt --force nutzen: Wenn du erzwingen musst, ist --force-with-lease sicherer, weil es scheitert, wenn seit deinem letzten Fetch jemand anderes gepusht hat (für zusätzliche Sicherheit --force-if-includes ergänzen).
  • ✓Beim ersten Push den Upstream setzen: Nutze 'git push -u origin branch-name' beim Pushen eines neuen Branches, um das Tracking einzurichten. Danach reicht ein einfaches 'git push'.
  • ✓Nie auf geteilte Branches force-pushen: Ein Force-Push auf main, master oder develop kann die Arbeit anderer zerstören. Nutze Revert-Commits statt die Historie umzuschreiben.
  • ✓Branch-Schutzregeln nutzen: Konfiguriere dein Repository so, dass Force-Pushes auf wichtige Branches verhindert und Reviews für Pull Requests verlangt werden.
  • ✓Oft pushen, um deine Arbeit zu sichern: Regelmäßige Pushes von Feature-Branches dienen als Backup und zeigen anderen deinen Fortschritt.
  • ✓Vor dem Pushen prüfen: Mit 'git push --dry-run' siehst du, was gepusht würde, ohne tatsächlich zu pushen. Ideal zum Gegenprüfen.
  • ✓Remote-Branches aufräumen: Lösche gemergte Feature-Branches mit 'git push origin --delete branch-name', damit das Remote-Repository ordentlich bleibt.
  • ✓Atomare Pushes für zusammenhängende Änderungen: Wenn du mehrere voneinander abhängige Branches pushst, sorgt '--atomic' dafür, dass alle durchgehen oder keiner.
  • ✓Wichtige Pushes signieren: In sicherheitskritischen Repositories signiert '--signed' deine Pushes mit GPG zur Überprüfung (der Server muss signierte Pushes unterstützen, sonst scheitert der Push).

Häufige Fehler

  • ✗Pushen, ohne vorher zu pullen: Hat das Remote neue Commits, wird dein Push abgelehnt. Führe immer zuerst 'git pull' aus (oder fetch, dann merge/rebase), um Remote-Änderungen aufzunehmen.
  • ✗--force auf geteilten Branches nutzen: Ein Force-Push schreibt die Historie um und kann die Arbeit anderer zerstören. Nutze stattdessen --force-with-lease oder vermeide Force-Pushes auf geteilte Branches am besten ganz.
  • ✗Vergessen, mit -u den Upstream zu setzen: Nutze beim ersten Push eines neuen Branches 'git push -u origin branch-name', um das Tracking einzurichten. Sonst musst du Remote und Branch jedes Mal angeben.
  • ✗Auf den falschen Branch pushen: Prüfe vor dem Push mit 'git branch' deinen aktuellen Branch. Nutze zur Sicherheit eine ausdrückliche Syntax wie 'git push origin feature:feature'.
  • ✗Abgelehnte Pushes nicht verstehen: 'non-fast-forward'-Fehler bedeuten, dass das Remote Commits hat, die du lokal nicht hast. Pulle und merge/rebase vor dem Pushen – erzwinge nicht einfach.

FAQ

A:

'git push' lädt deine lokalen Commits in ein Remote-Repository hoch und macht deine Änderungen für andere verfügbar. 'git pull' lädt Commits von einem Remote herunter und mergt sie in deinen lokalen Branch. Push schickt Daten raus; Pull holt Daten rein.

A:

Einen Push kann man nicht wirklich „rückgängig“ machen, da er geteilte Historie ist. Sicher zurücknehmen kannst du ihn mit 'git revert HEAD', das einen neuen Commit erzeugt, der die Änderungen aufhebt – dann erneut pushen. Vermeide 'git reset' + Force-Push auf geteilten Branches, da es Historie umschreibt, die andere vielleicht schon gepullt haben.

A:

Die Option -u richtet eine Tracking-Beziehung zwischen deinem lokalen Branch und dem Remote-Branch ein. Nach 'git push -u origin feature' reichen 'git push' und 'git pull', ohne jedes Mal Remote und Branch anzugeben.

A:

Force-Push (--force) sollte nur auf Branches genutzt werden, an denen du allein arbeitest, etwa persönliche Feature-Branches nach einem Rebase. Force-pushe nie auf geteilte Branches wie main oder develop. Wenn es sein muss, nutze zur Sicherheit --force-with-lease.

A:

Nutze die Refspec-Syntax: 'git push origin local-branch:remote-branch'. Zum Beispiel pusht 'git push origin feature:experiment' deinen lokalen Branch 'feature' auf einen Remote-Branch namens 'experiment'.

A:

Meist, weil das Remote Commits hat, die du lokal nicht hast (non-fast-forward). Führe 'git pull' aus, um diese Änderungen zu holen und zu mergen, löse eventuelle Konflikte und pushe dann erneut. Erzwinge nichts, außer du bist sicher, dass es gefahrlos ist.

A:

Nutze 'git push --all origin', um alle lokalen Branches zum Remote zu pushen. Tags brauchen einen eigenen Befehl, weil sich '--all' und '--tags' nicht kombinieren lassen: 'git push --tags origin'.

A:

'--force' überschreibt den Remote-Branch blind, egal in welchem Zustand er ist. '--force-with-lease' überschreibt nur, wenn sich das Remote seit deinem letzten Fetch nicht geändert hat – es scheitert, wenn jemand anderes gepusht hat, und schützt so dessen Arbeit. Achtung: Ein Fetch (auch ein Hintergrund-Fetch deiner IDE) frischt diese Prüfung auf, also ergänze --force-if-includes, um zusätzlich zu verlangen, dass du das Geholte integriert hast.

A:

Nutze 'git push origin --delete branch-name' oder die Kurzform 'git push origin :branch-name'. Beide entfernen den Branch aus dem Remote-Repository.

A:

Ein einfaches 'git push' funktioniert nur, wenn für den aktuellen Branch ein Upstream-Branch konfiguriert ist. Bei neuen Branches brauchst du zuerst 'git push -u origin branch-name'. Prüfe die Tracking-Beziehungen mit 'git branch -vv'.