Local History vs. Git: Wann welches Werkzeug in PhpStorm rettet

1. Was Local History überhaupt ist

Local History ist eine in PhpStorm eingebaute, automatische Versionierung, die bei jedem Speichern einer Datei im Hintergrund einen Snapshot anlegt, vollkommen unabhängig von Git und ohne dass ein Entwickler dafür irgendetwas tun muss. Anders als bei einem Commit ist kein bewusster Akt nötig, jede noch so kleine Änderung, jeder Tippfehler-Fix und jedes automatische Refactoring landet automatisch als eigener Eintrag in der Historie einer Datei oder eines ganzen Verzeichnisses.

Das macht Local History zu einem Sicherheitsnetz gerade für den Zustand zwischen zwei Commits, also genau den Bereich, in dem Git von Haus aus nichts speichert. Wer während eines längeren Refactorings mehrfach experimentiert, wieder verwirft und neu ansetzt, ohne jeden Zwischenschritt zu committen, verlässt sich in der Praxis fast immer auf Local History, auch wenn viele Entwickler das Werkzeug nie bewusst wahrnehmen, bis sie es zum ersten Mal dringend brauchen.

2. Wie Local History technisch funktioniert

Local History speichert ihre Snapshots in einem projektinternen, IDE-verwalteten Verzeichnis außerhalb des eigentlichen Arbeitsbaums, sodass sie weder im Git-Verlauf noch in einem Backup des Projektordners auftaucht, sofern dieses nicht auch die IDE-Konfiguration mit einschließt. Die Speicherung erfolgt inkrementell, es wird also nicht bei jedem Save eine komplette Kopie jeder Datei angelegt, sondern nur die Differenz zum vorherigen Zustand, was den Speicherbedarf trotz sehr feiner Granularität überschaubar hält.

Weil die Historie an das jeweilige Projekt auf dem jeweiligen Rechner gebunden ist, überlebt sie weder einen Rechnerwechsel noch das Löschen und erneute Klonen des Projektordners. Ein frisch aus Git ausgechecktes Projekt startet immer mit leerer Local History, ganz gleich wie viele Commits das Repository bereits enthält, was den fundamentalen Unterschied zu Git noch einmal unterstreicht: Local History ist lokal und flüchtig, Git ist verteilt und dauerhaft.

3. Die Local-History-Oberfläche in der Praxis

Der Zugriff erfolgt über einen Rechtsklick auf eine Datei, einen Ordner oder das gesamte Projekt im Projektbaum, gefolgt von Local History, Show History. PhpStorm öffnet daraufhin eine Zeitleiste mit allen gespeicherten Zwischenständen, zwischen denen sich per Diff-Ansicht wie bei einem Git-Vergleich navigieren lässt, inklusive farblich markierter Zeilen für Hinzufügungen und Löschungen.

Aus dieser Ansicht heraus lässt sich jeder frühere Stand direkt wiederherstellen, entweder die komplette Datei per Revert oder gezielt einzelne Codeblöcke per Copy-Paste aus der historischen Ansicht in die aktuelle Datei. Für ganze Ordner funktioniert das analog: Ein versehentlich gelöschtes Unterverzeichnis lässt sich über Local History auf Ordnerebene oft komplett wiederherstellen, selbst wenn keine einzige Datei davon jemals committet wurde.

Wiederherstellung ueber Local History:

1. Rechtsklick auf Datei/Ordner im Project-Baum
2. Local History -> Show History
3. Zeitpunkt vor dem Problem auswaehlen
4. Diff pruefen (links: aktuell, rechts: historisch)
5. "Revert" fuer die komplette Datei
   ODER: einzelne Zeilen aus der historischen Ansicht kopieren

Zusaetzlich: "Local History -> Put Label" VOR einem riskanten
Refactoring setzt einen benannten Wiederherstellungspunkt.

4. Szenarien, in denen Local History rettet

Der klassische Fall ist eine Datei, die versehentlich überschrieben oder gelöscht wurde, bevor sie jemals committet war, etwa nach einem übereifrigen Suchen-und-Ersetzen über mehrere Dateien hinweg, das mehr verändert hat als beabsichtigt. Weil Git per Definition nur das kennt, was im Index oder in einem Commit steht, ist ein ungecommiteter Verlust für Git unsichtbar, für Local History dagegen ein ganz normaler, jederzeit abrufbarer Zwischenstand.

Ebenso rettet Local History nach einem IDE-Absturz während einer laufenden, noch nicht gespeicherten Änderung, weil PhpStorm periodisch auch Zwischenstände ungesicherter Buffer erfasst, und nach dem Überschreiten des eigenen Undo-Limits, das bei sehr langen Editier-Sitzungen irgendwann an sein Ende kommt, während Local History deutlich weiter zurückreicht. Auch beim versehentlichen kompletten Verwurf aller Änderungen per git checkout mit doppeltem Bindestrich und Punkt, der lokale, ungecommitete Änderungen kommentarlos verwirft, bleibt Local History oft der einzige Weg zurück.

5. Wo Git klar überlegen ist

Git ist immer dann die richtige Wahl, wenn es um geteilte, dauerhafte und nachvollziehbare Historie über mehrere Entwickler und Rechner hinweg geht. Ein Commit mit aussagekräftiger Nachricht dokumentiert eine bewusste, fachlich sinnvolle Änderungseinheit, die sich per Blame einem Autor zuordnen, per Tag als Release markieren und per Pull-Request diskutieren lässt, alles Fähigkeiten, die Local History als rein lokales, unstrukturiertes Snapshot-Archiv grundsätzlich nicht bietet.

Für Branching, das gezielte Rückgängigmachen einer bestimmten fachlichen Änderung per Revert, das Zusammenführen paralleler Arbeitsstränge oder die langfristige Aufbewahrung über Jahre hinweg ist Git ohne Alternative. Ein Projekt, das ausschließlich auf Local History vertraut und nie committet, verliert seine gesamte Historie beim nächsten Rechnerwechsel, während ein Git-Repository beliebig oft geklont und dadurch effektiv beliebig oft gesichert werden kann.

6. Ein konkreter Recovery-Workflow

Ein typisches Schadensbild in einem Magento-Projekt: Ein Entwickler führt in PhpStorm ein automatisches Refactoring über mehrere Plugin-Klassen aus, bemerkt danach, dass eine wichtige, individuelle Anpassung in einer der Dateien dabei überschrieben wurde, hat aber vor dem Refactoring nicht committet. Der erste Schritt ist, ruhig zu bleiben und keine weiteren Speicheraktionen in der betroffenen Datei vorzunehmen, um die relevanten Local-History-Einträge nicht zu überschreiben.

Dann folgt der Blick in Local History, Show History für genau diese Datei, das Auffinden des Zeitpunkts kurz vor dem Refactoring anhand der Zeitstempel, und ein gezielter Diff gegen den aktuellen Stand. Häufig reicht es, nur den verlorenen Codeblock aus der historischen Ansicht zu kopieren, statt die gesamte Datei zu ersetzen, damit die zwischenzeitlich vom Refactoring korrekt vorgenommenen Änderungen erhalten bleiben.

7. Manuelle Labels vor riskanten Refactorings

Über Local History, Put Label lässt sich ein benannter Wiederherstellungspunkt setzen, der in der Zeitleiste deutlich hervorgehoben erscheint und damit leichter wiederzufinden ist als ein automatischer Snapshot zwischen hunderten anderen. Vor einem größeren, automatisierten Refactoring über viele Dateien, etwa dem Umbenennen einer zentralen Interface-Methode in einem Magento-Modul, ist ein solches Label eine günstige Versicherung, die wenige Sekunden kostet.

Das Label ersetzt keinen Commit, ist aber die schnellere Option für einen Zwischenstand, den man nicht ins Git-Repository aufnehmen möchte, etwa weil der Code noch nicht kompiliert oder erst ein halbfertiger Zwischenschritt ist. In Kombination mit einem tatsächlichen Commit direkt vor dem Refactoring bietet sich die stärkste Absicherung: Git für den offiziellen letzten sauberen Stand, das Label für den exakten Zeitpunkt kurz davor innerhalb der IDE.

8. Grenzen und Aufbewahrungsdauer

Local History bewahrt Einträge standardmäßig für einen begrenzten Zeitraum auf, konfigurierbar über Settings, Advanced Settings, Local History mit Optionen für die maximale Aufbewahrungsdauer und den maximalen Speicherplatz, wonach ältere Einträge automatisch gelöscht werden. Für ein Projekt mit sehr aktiver, langjähriger Entwicklung reicht die Standardeinstellung meist nicht aus, um Monate zurückzuschauen, weshalb Local History niemals als Ersatz für regelmäßige Commits gedacht ist, sondern als Ergänzung für den kurzfristigen Bereich.

Eine weitere Grenze: Local History ist strikt an das lokale Projektverzeichnis auf dem jeweiligen Rechner gebunden und lässt sich nicht auf einen anderen Rechner übertragen, mit einem Kollegen teilen oder in ein Backup-System außerhalb der IDE exportieren. Wer regelmäßig zwischen mehreren Maschinen wechselt, etwa Homeoffice und Büro-Rechner, kann sich auf Local History deshalb nur für den jeweils aktuell genutzten Rechner verlassen, nicht projektübergreifend.

9. Beide Werkzeuge kombiniert in der Praxis

In der täglichen Arbeit ergänzen sich beide Werkzeuge, statt in Konkurrenz zu stehen: kleine, häufige Commits für die dauerhafte, teamfähige Historie, plus Local History als engmaschiges Sicherheitsnetz für den Bereich zwischen den Commits, in dem experimentiert, verworfen und neu angesetzt wird. Ein Entwickler, der beide Werkzeuge kennt, verliert praktisch nie mehr als wenige Minuten Arbeit, selbst im schlimmsten Fall eines IDE-Absturzes mitten in einem komplexen Refactoring.

Die folgende Tabelle fasst zusammen, welches Werkzeug in welchem Szenario die richtige Wahl ist, gemessen an Reichweite, Teamfähigkeit und typischem Rettungsfall in einem PHP- oder Magento-Projekt.

10. Zusammenfassung

11. FAQ: Local History vs. Git: Das Wichtigste auf einen Blick