5 Git-Befehle jenseits von Commit und Push

Die meisten Entwickler bewegen sich ausschließlich in add, commit, push und pull — die eigentliche Hebelwirkung von Git steckt jedoch in den Befehlen zur Wiederherstellung, zum Bearbeiten der Historie und zum Debugging, die der tägliche Arbeitsablauf nie berührt.

Meist lernt man den Rest auf die harte Tour kennen. Ein reset --hard verschluckt die Arbeit eines ganzen Nachmittags, oder irgendwo in 200 Commits taucht ein Bug auf und niemand kann sagen, welcher davon ihn verursacht hat. Die folgenden fünf Befehle lösen Probleme, an denen die Grundlagen scheitern: halbfertige Arbeit zwischenlagern, verloren geglaubte Commits wiederherstellen, einen einzelnen Fix zwischen Branches verschieben, unaufgeräumte Historie vor einem PR bereinigen und exakt den Commit ermitteln, der einen Bug eingeführt hat. Zu jedem gibt es einen mentalen Auslöser, die genaue Syntax und den einen Stolperstein, über den alle fallen.

git stash: Arbeit zwischenlagern, um schnell den Kontext zu wechseln

Nutze das, wenn ein Bug-Report hereinkommt, während dein Working Tree ein halbfertiges Durcheinander ist und du sofort den Branch wechseln musst. git stash parkt deine nicht committeten Änderungen an einem sicheren Ort und gibt dir das Working Tree sauber zurück — im Zustand deines letzten Commits. Ein Wegwerf-Commit mit „WIP” ist nicht nötig.

git stash                  # shelve tracked changes, clean the tree
git stash --include-untracked   # also shelve new, untracked files
git stash list             # see all stashes: stash@{0}, stash@{1}, ...
git stash pop              # reapply the latest stash and delete it
git stash apply stash@{1}  # reapply a specific stash, keep it in the list

Der Stolperstein: pop und apply sind nicht austauschbar. git stash pop wendet die zwischengelagerten Änderungen an und löscht den Stash; git stash apply wendet sie an, behält den Stash aber — was sicherer ist, wenn beim erneuten Anwenden Konflikte auftreten könnten. Führt ein pop zu einem Merge-Konflikt, wird der Stash nicht verworfen. Löse zuerst den Konflikt und prüfe dann nach, statt anzunehmen, er sei bereits weg.

git reflog: Arbeit wiederherstellen, die du verloren geglaubt hast

Nutze das, wenn ein missglücktes reset --hard, ein verpatzter Rebase oder ein gelöschter Branch Commits verschwinden lässt und Panik aufkommt. git reflog protokolliert jede Position, die HEAD in deinem lokalen Repository eingenommen hat — der „verlorene” Commit existiert also fast immer noch. Du brauchst nur seinen Hash.

git reflog
# ab12cd3 HEAD@{0}: reset: moving to HEAD~1
# ef45gh6 HEAD@{1}: commit: the work you thought vanished
git reset --hard ef45gh6   # restore HEAD to that commit
# or, to inspect it on a new branch first:
git switch -c recovery ef45gh6

Finde die Ref für den gewünschten Zustand und springe mit git reset --hard <ref> dorthin zurück — oder checke sie in einen neuen Branch aus, um sie zunächst gefahrlos zu inspizieren. Das ist der „Oh nein, meine Arbeit ist weg”-Held im Werkzeugkasten.

Der Stolperstein: Das Reflog ist strikt lokal und gilt pro Clone. Es wird nicht zum Remote übertragen und existiert in einem frischen Clone nicht — erneutes Klonen, um „die Arbeit zurückzuholen”, hilft also nicht. Einträge werden zudem im Lauf der Zeit von der Garbage Collection entfernt, also lieber früher als später wiederherstellen.

git cherry-pick: einen einzelnen Commit zwischen Branches verschieben

Nutze das, wenn ein einzelner Hotfix-Commit in einem Release-Branch landen soll, du aber nicht den gesamten Feature-Branch mergen willst, aus dem er stammt. git cherry-pick <hash> kopiert genau einen bestimmten Commit auf deinen aktuellen Branch und lässt alles andere zurück.

git switch release-2.4
git cherry-pick 9f3c1a7        # apply one commit here
git cherry-pick 9f3c1a7 3b8e2d0   # apply several, in order

Der Stolperstein: Cherry-Pick erzeugt einen neuen Commit mit einem neuen Hash. Das Original bleibt weder erhalten noch wird es verschoben. Wenn derselbe Commit später über einen regulären Merge in diesen Branch gelangt, können doppelte Änderungen in der Historie landen. Setze den Befehl gezielt ein, nicht als routinemäßigen Ersatz für einen Merge.

git rebase -i: Historie vor einem PR aufräumen

Nutze das, wenn dein Feature-Branch fünf „fix typo”- und „wip”-Commits enthält und du vor dem Öffnen eines Pull Requests eine aufgeräumte, review-freundliche Historie möchtest. git rebase -i <base-branch> öffnet einen Editor, in dem du Commits neu anordnen, zusammenfassen, bearbeiten oder verwerfen kannst.

git rebase -i main
# pick   a1b2c3d Add feature scaffold
# squash e4f5g6h fix typo
# reword h7i8j9k Wire up handler
# drop   k0l1m2n debug logging

Markierst du einen Commit mit squash, wird er in den darüberliegenden eingegliedert; reword ändert nur seine Nachricht, und drop entfernt ihn vollständig aus dem Ergebnis. Wenn du lediglich einen kompletten Branch zu einer einzigen gestagten Änderung zusammenfassen willst, ist git merge --squash <branch> das Schwesterwerkzeug. Es staged die kombinierten Änderungen, ohne einen Commit zu erzeugen — den git commit führst du also weiterhin selbst aus.

Der Stolperstein und die goldene Regel: Schreibe die Historie ruhig um, solange sie lokal ist, aber rebase niemals Commits, die du bereits in einen geteilten Branch gepusht hast. Das Umschreiben geteilter Historie zwingt alle anderen zu schmerzhafter Nacharbeit — eine Gefahr, die Pro Git „The Perils of Rebasing” nennt.

git bisect: den Commit finden, der einen Bug eingeführt hat

Nutze das, wenn etwas letzte Woche noch funktionierte und jetzt kaputt ist und du keine Ahnung hast, welcher von 200 Commits dafür verantwortlich ist. git bisect führt eine Binärsuche durch die Historie durch: Markiere einen fehlerhaften und einen funktionierenden Commit, teste die Mittelpunkte, die Git auscheckt, und der Befehl ermittelt den ersten fehlerhaften Commit in log₂(n) Schritten.

git bisect start
git bisect bad                 # current commit is broken
git bisect good v2.3.0         # this older tag worked
# Git checks out a midpoint — test it, then tell Git:
git bisect good                # this one is fine
git bisect bad                 # this one is broken
# ...repeat until Git reports "<hash> is the first bad commit"
git bisect reset               # return HEAD to where you started

Die gesamte Suche lässt sich automatisieren: git bisect run <script> nutzt den Exit-Status eines Skripts, um jeden Commit ohne manuelle Eingabe als „good” oder „bad” zu markieren. Beende jede Sitzung mit git bisect reset, damit HEAD zu dem Punkt zurückkehrt, an dem du vor der Suche gestartet bist.

Der Stolperstein: Bisect setzt voraus, dass sich jeder ausgecheckte Commit sauber bauen und testen lässt. Ein Commit, der aus einem unabhängigen Grund nicht kompiliert, verfälscht das Ergebnis. Markiere solche Fälle mit git bisect skip, statt „good” oder „bad” zu raten.

Ein Sicherheitsnetz für die destruktiven Befehle

Zwei dieser Befehle schreiben Historie um, und für beide gilt dieselbe Regel: git rebase -i und git reset --hard sind bei lokaler, noch nicht gepushter Arbeit sicher und bei geteilten Branches gefährlich. Wenn du ein sicheres Undo auf einem Branch brauchst, den andere bereits gepullt haben, greife zu git revert — der Befehl erzeugt einen neuen Commit, der die Änderung rückgängig macht, ohne die bestehende Historie anzutasten. Und wenn ein lokales Umschreiben schiefgeht, ist git reflog die Notausstiegsluke, die dir deine Commits zurückholt.

Diese fünf Befehle verdienen ihren Platz, weil jeder eine Frage beantwortet, die commit und push nicht beantworten können: das hier sichern, jenes wiederherstellen, eines verschieben, aufräumen, den Bug jagen. Verknüpfe jeden mit seinem Auslöser und greife danach, sobald die Situation eintritt.

FAQs

Was ist der Unterschied zwischen git reset --hard und git revert?

git reset --hard setzt HEAD zurück und verwirft Commits, schreibt also die Historie um — was den Befehl auf jedem Branch gefährlich macht, den andere bereits gepullt haben. git revert erzeugt stattdessen einen neuen Commit, der die betreffende Änderung rückgängig macht, während die bestehende Historie unangetastet bleibt. Verwende reset --hard nur für lokale, noch nicht gepushte Arbeit; nutze revert als sicheres Undo auf geteilten Branches. Geht ein Reset schief, kann git reflog die verworfenen Commits über ihren Hash wiederherstellen.

Wie stelle ich einen Commit wieder her, den git reset --hard gelöscht hat?

Führe git reflog aus — es protokolliert jede Position, die HEAD in deinem lokalen Repository eingenommen hat. Suche den Eintrag für den gewünschten Zustand, notiere dessen Hash und führe dann git reset --hard <hash> aus, um ihn wiederherzustellen, oder git switch -c recovery <hash>, um ihn zunächst in einem neuen Branch zu inspizieren. Das Reflog ist lokal und gilt pro Clone, erneutes Klonen holt die Arbeit also nicht zurück. Einträge werden zudem im Lauf der Zeit von der Garbage Collection entfernt — stelle sie also lieber früher als später wieder her.

Ersetzt git switch das Kommando git checkout beim Branch-Wechsel?

git switch und git restore wurden in Git 2.23 (August 2019) eingeführt, um die überladenen Aufgaben von git checkout aufzuteilen: switch übernimmt den Wechsel zwischen Branches, restore das Wiederherstellen von Dateien. Beide Manpages trugen jahrelang einen Experimental-Hinweis, doch dieser wurde mit Git 2.55.0 entfernt — sie sind damit schlicht die empfohlenen Befehle für diese Aufgaben. git checkout funktioniert weiterhin und ist nicht als veraltet markiert, bestehende Workflows bleiben also gültig.

Wann sollte ich git cherry-pick statt eines Merges verwenden?

Verwende git cherry-pick, wenn du exakt einen Commit auf einem anderen Branch benötigst (etwa um einen einzelnen Hotfix in einen Release-Branch zu übernehmen), ohne die restliche Historie des Quell-Branches mitzuziehen. Ein Merge bringt sämtliche Änderungen des Branches mit und ist damit das falsche Werkzeug, um einen einzelnen Fix zu isolieren. Beachte, dass cherry-pick einen neuen Commit mit neuem Hash erzeugt — kommt dieselbe Änderung später über einen regulären Merge hinzu, können doppelte Änderungen in der Historie landen.