Git: Branches löschen, mergen und einen schlechten Push rückgängig machen

August 2, 2026 · – Besucher

Diese drei Dinge kommen ständig vor, und irgendwie bleiben einem die Befehle nie so richtig von einem Mal zum nächsten im Kopf. Also hier sind sie, ordentlich aufgeschrieben.

Einen Branch löschen

git branch -d feature-x

Das ist die sichere Variante — Git prüft vorher und verweigert es, wenn feature-x Commits enthält, die es nie in Ihren aktuellen Branch geschafft haben. Wenn Sie sich sicher sind, können Sie das erzwingen: (1)

git branch -D feature-x

Das löscht ihn allerdings nur lokal. Wenn der Branch auch remote existiert (zum Beispiel auf GitHub), müssen Sie ihn dort separat löschen:

git push origin --delete feature-x

Etwas, das man wissen sollte: Das Löschen eines Branches löscht dessen Commits nicht wirklich. Sie werden nur unreferenziert und bleiben im Repository liegen, bis der Garbage Collector von Git sie irgendwann einsammelt — das kann eine Weile dauern. git branch -D ist also nachsichtiger, als es aussieht — löscht man den falschen Branch, gibt es meistens noch einen Weg zurück (mehr dazu im Reflog-Abschnitt weiter unten). Ich würde mich nicht als Plan darauf verlassen, aber es ist gut zu wissen, dass es diese Möglichkeit gibt.

Branches mergen

Das übliche Muster: Zunächst den Branch auschecken, in den gemergt werden soll, dann den anderen hineinmergen.

git checkout main
git merge feature-x

Was als Nächstes passiert, hängt davon ab, ob sich main bewegt hat, seit der Branch abgezweigt wurde. Wenn nicht, schiebt Git den main-Zeiger einfach vor, sodass er mit feature-x übereinstimmt — ein Fast-Forward, ganz ohne Merge-Commit. Hat sich main in der Zwischenzeit weiterentwickelt, erstellt Git einen echten Merge-Commit, der beide Historien zusammenführt (2).

Manchmal will man diesen Merge-Commit auch dann, wenn ein Fast-Forward möglich gewesen wäre — er hinterlässt eine sichtbare Markierung in der Historie, dass ein Feature-Branch existierte und gemergt wurde, statt dass sich die Änderung still einfügt. Dafür:

git merge --no-ff feature-x

Wenn auf beiden Seiten dieselben Zeilen angefasst wurden, stoppt Git und überlässt Ihnen den Konflikt zum Auflösen:

git status

Das listet auf, welche Dateien in Konflikt stehen. Öffnen Sie jede davon, Sie sehen <<<<<<<, ======= und >>>>>>>-Marker rund um die konkurrierenden Änderungen — wählen Sie aus, was tatsächlich bleiben soll, löschen Sie die Marker, dann:

git add resolved-file.txt
git commit

Und wenn sich das Ganze eher als Chaos entpuppt, als es wert ist, kann man einfach von der ganzen Sache zurücktreten:

git merge --abort

Das setzt alles genau so zurück, wie es vor Beginn des Merges war.

Einen schlechten Push rückgängig machen

Das ist der Fall, bei dem Leute in Panik geraten, und ehrlich gesagt ist die Panik meist unbegründet — aber welche Lösung man wählt, ist hier tatsächlich entscheidend.

Wenn auch nur die Möglichkeit besteht, dass jemand anders den Branch schon gepullt hat, fassen Sie die Historie nicht an. Fügen Sie stattdessen einen neuen Commit hinzu, der den alten rückgängig macht:

git revert <bad-commit-sha>
git push

Das ist die langweilige, immer sichere Option. Sie schreibt nichts um — sie fügt lediglich einen Commit obendrauf hinzu, der den Fehler aufhebt, sodass die Historie für alle synchron bleibt, ohne dass jemand auf seiner Seite etwas Besonderes tun muss (3).

Wenn der Branch wirklich nur Ihnen gehört und ihn noch niemand gepullt hat, können Sie zurückspulen und umschreiben: (4)

git reset --hard <last-good-commit-sha>
git push --force-with-lease

Nutzen Sie --force-with-lease, nicht das einfache --force, und sei es nur aus Gewohnheit. Der Unterschied ist wichtiger, als es scheint: --force-with-lease prüft, ob seit Ihrem letzten Fetch niemand auf den Branch gepusht hat, und verweigert den Push, falls doch. Das einfache --force prüft gar nichts — es überschreibt fröhlich die Arbeit anderer, ohne auch nur eine Warnung (5).

Und wenn Sie vor Ihrem Terminal sitzen und versuchen, sich zu erinnern, was der letzte gute Commit überhaupt war — git log hilft hier nicht weiter, da es nur Commits zeigt, die von Ihrer aktuellen Position aus erreichbar sind, was das, wovon Sie sich mit dem Reset bereits getrennt haben, nicht einschließt. Was Sie wollen, ist:

git reflog

Es zeigt jede Stelle, auf die Ihr Branch zuletzt zeigte, einschließlich derer, die aus der normalen Historie herausgefallen sind. Scrollen Sie zurück bis vor den Punkt, an dem es schiefging, dann: (6)

git reset --hard HEAD@{2}

(setzen Sie stattdessen die Position oder den SHA ein, der tatsächlich zu Ihrem Fall passt). Das Reflog ist lokal auf Ihrem Rechner und behält Einträge in der Regel etwa 90 Tage lang — es ist also weniger ein „Notfall-Rückgängig für schlechte Pushes" und eher ein allgemeines Sicherheitsnetz für „ich glaube, ich habe gerade etwas kaputtgemacht" — es lohnt sich, sich daran zu erinnern, dass es das gibt, auch abseits dieser konkreten Situation.

Schlussgedanke

Alle drei Dinge stützen sich auf dieselbe zugrunde liegende Tatsache: Git wirft fast nie sofort etwas weg. Gelöschte Branches, zurückgesetzte Commits, alte Positionen auf einem Branch — sie alle bleiben länger erhalten, als es scheint. Genau das macht -D, reset --hard und Force-Push sicher genug für den Alltagsgebrauch, solange man weiß, wo man nachschauen muss, falls sich einer davon als Fehler herausstellt.

Weiterführende Artikel

• Make verstehen — was einen Neubau tatsächlich auslöst

Weiterführende Links

1. git-branch — Branch-Erstellung, -Auflistung und -Löschung.
2. git-merge — Merge-Strategien und Konfliktlösung.
3. git-revert — Commits rückgängig machen, indem neue erstellt werden.
4. git-reset — den Zeiger eines Branches verschieben, mit dem Unterschied zwischen --soft, --mixed und --hard.
5. git-push: --force-with-lease — warum es sicherer ist als --force.
6. git-reflog — Commits wiederherstellen, die in der normalen Historie nicht mehr auftauchen.