Code Reviews in PhpStorm vorbereiten: Diffs, History, Blame und TODOs

1. Code Reviews in der IDE vorbereiten – warum das sinnvoll ist

Ein Code Review ist nur so gut wie der Kontext, den der Reviewer hat. Wer einen Pull Request in der GitHub-Oberfläche reviewt, sieht flache Diffs ohne Zugriff auf die vollständige Dateihistorie, ohne Live-Analyse der statischen Code-Qualität und ohne die Möglichkeit, direkt in den Code zu navigieren. PhpStorm löst dieses Problem, indem alle review-relevanten Werkzeuge – Diff-Viewer, Git Log, Annotate-Ansicht und TODO-Tracker – tief in die IDE integriert sind.

Für PHP-Teams, die an Magento-Projekten oder anderen großen PHP-Codebasen arbeiten, ist der Unterschied besonders deutlich: Ein Diff in der GitHub-Oberfläche zeigt, dass eine Methode geändert wurde. Der PhpStorm-Diff zeigt gleichzeitig, ob die Methode die Interface-Anforderungen noch erfüllt, ob eine unresolvte Abhängigkeit entsteht und ob PHPDoc-Kommentare zur neuen Signatur passen. Diese Kombination aus Versionskontrolle und statischer Analyse macht Reviews gründlicher und schneller.

Der Artikel zeigt, wie die einzelnen Werkzeuge von PhpStorm für strukturierte Reviews eingesetzt werden, welche Tastenkombinationen dabei entscheidend sind und welche Einstellungen den Workflow verbessern – mit dem Ziel, Reviews als Teil des normalen Entwicklungsalltags in der IDE abzubilden statt als separaten Browser-Prozess.

2. Der Diff-Viewer: Änderungen im Kontext verstehen

Der Diff-Viewer von PhpStorm öffnet sich in mehreren Kontexten: beim Öffnen einer Datei aus dem Changes-Panel (Alt+9), beim Vergleich zweier Branches aus dem Git-Log oder beim direkten Aufrufen von Ctrl+D auf einer Datei. Der entscheidende Vorteil gegenüber Web-Diffs ist die Side-by-Side-Ansicht mit vollständiger Syntax-Hervorhebung, Navigation per Pfeil-Buttons zwischen Änderungsblöcken und der Möglichkeit, direkt im rechten Panel zu editieren.

In der Diff-Ansicht stehen alle PhpStorm-Navigationsfeatures zur Verfügung: Ctrl+Click auf einen Klassennamen navigiert zur Deklaration, Alt+F7 zeigt alle Verwendungen, Ctrl+Q öffnet das Quick-Documentation-Popup. Das erlaubt es, beim Review einer Methode sofort zu sehen, ob die aufgerufenen Methoden existieren, die korrekten Parameter erwarten und dokumentiert sind – ohne den Diff-Viewer zu verlassen.

Für Branch-Vergleiche öffnet man über Alt+9 das Git-Panel, wählt einen Branch mit Rechtsklick und dann "Compare with Current". PhpStorm zeigt alle geänderten Dateien mit ihren Diff-Vorschauen. Die Filterfunktion im Changes-Panel erlaubt es, Dateien nach Typ zu filtern – etwa nur PHP-Dateien oder nur Template-Dateien – und so Reviews für große Feature-Branches systematisch aufzuteilen.

<?php
// Before: method without return type (visible in left diff panel)
class OrderProcessor
{
    public function process($order)
    {
        // implementation
    }
}

// After: typed, with interface contract (visible in right diff panel)
// PhpStorm diff highlights: return type added, interface implemented
class OrderProcessor implements OrderProcessorInterface
{
    public function process(OrderInterface $order): ProcessResultInterface
    {
        // PhpStorm: Ctrl+Click on ProcessResultInterface -> navigate to declaration
        // PhpStorm: Alt+F7 on process() -> find all usages instantly
        return $this->executeProcessing($order);
    }
}

3. File History und Log: Warum wurde diese Zeile geändert?

Die File History in PhpStorm zeigt die vollständige Git-Commit-Geschichte einer einzelnen Datei – zugänglich über Rechtsklick auf die Datei im Project-Tree und dann "Git > Show History" oder über Alt+9 und dann das History-Tab im Git-Panel. Jeder Commit in der Liste zeigt Autor, Datum, Commit-Message und kann direkt als Diff zum Vorgänger geöffnet werden.

Besonders wertvoll beim Review ist die Funktion "Show History for Selection": Man markiert einen Codeblock und ruft die History nur für diesen Block auf. Das zeigt, welche Commits genau diesen Bereich in der Vergangenheit berührt haben – ideal für die Frage, warum ein komplexer Algorithmus so geschrieben ist wie er ist. In Magento-Projekten, wo Plugin-Chains und Event-Dispatching nicht immer offensichtlich aus dem Code hervorgehen, liefert diese Ansicht entscheidenden Kontext.

Das Git Log im Vollbild (Alt+9, dann "Log"-Tab) zeigt die gesamte Repository-Historie mit Filter-Optionen nach Branch, Autor, Datum und Commit-Message. Die "Show Diff"-Aktion direkt aus dem Log öffnet den vollständigen Diff des Commits. Mit der Branch-Vergleichsfunktion lässt sich der genaue Commit-Unterschied zwischen feature-Branch und main visualisieren – als Liste aller Commits mit ihren Diffs, in derselben Reihenfolge wie sie entstanden sind.

<?php
// PhpStorm File History workflow for reviewing legacy code:
//
// 1. Right-click on file -> Git -> Show History
// 2. Each commit listed: date, author, message, changed lines
// 3. Double-click commit -> full diff opens in Diff-Viewer
// 4. For specific block: select lines -> Right-click -> Git -> Show History for Selection
//
// Example: complex Magento plugin chain — understanding WHY it exists
class ProductPricePlugin
{
    /**
     * Applied in commit a3f8b2: hotfix for rounding error in EUR pricing
     * Visible in File History: "Fix: EUR price rounding SC-1042"
     * Without history: looks like unnecessary complexity
     */
    public function afterGetFinalPrice(
        \Magento\Catalog\Model\Product $subject,
        float $result
    ): float {
        // Two-decimal rounding enforced after discount calculation
        return round($result, 2);
    }
}

4. Annotate (Git Blame): Herkunft jeder Zeile nachvollziehen

Die Annotate-Ansicht in PhpStorm entspricht git blame auf der Kommandozeile, ist aber deutlich komfortabler nutzbar: Über Rechtsklick im Editor-Gutter (die linke Randleiste mit Zeilennummern) und "Annotate with Git Blame" wird für jede Zeile der zugehörige Commit, Autor und Zeitstempel eingeblendet. Ein Klick auf einen Commit-Hash öffnet den vollständigen Diff dieses Commits.

Im Review-Kontext ist die Annotate-Ansicht besonders wertvoll für Zeilen, die im aktuellen Diff nicht geändert wurden, aber im Zusammenhang stehen. Wenn eine neue Methode eine bestehende Hilfsfunktion aufruft, zeigt Annotate sofort, wann und von wem diese Funktion zuletzt geändert wurde – und ob sie Teil eines anderen laufenden Features ist, das noch nicht gemergt wurde.

PhpStorm unterstützt auch "Annotate Previous Revision" – man kann sich durch die Blame-Geschichte einer Zeile rückwärts arbeiten und sehen, wie sich eine Zeile über mehrere Commits entwickelt hat. Das ist das leistungsfähigste Werkzeug um zu verstehen, warum eine Implementierung existiert und ob sie mit Absicht so gestaltet wurde. Kombiniert mit der Möglichkeit, direkt aus dem Annotate-Panel in den Commit-Diff zu wechseln, entsteht ein vollständiger Kontext ohne Terminal.

5. TODO-Tracker: Offene Punkte sichtbar machen

Der TODO-Tracker in PhpStorm aggregiert alle TODO-Kommentare im Projekt in einer durchsuchbaren Liste – erreichbar über "View > Tool Windows > TODO" oder Alt+6. Standardmäßig erkennt PhpStorm TODO, FIXME, HACK und XXX als Marker. Eigene Marker lassen sich unter "Settings > Editor > TODO" mit regulären Ausdrücken definieren und farblich hervorheben.

Für Code Reviews ist der TODO-Tracker auf zwei Arten wertvoll: Erstens zeigt er, welche TODOs durch den aktuellen Branch neu hinzugekommen sind – diese sollten im Review explizit kommentiert werden. Zweitens können TODOs genutzt werden um Review-Notizen direkt im Code zu hinterlassen: Ein temporärer // REVIEW: Warum kein Interface?-Kommentar erscheint sofort im TODO-Panel und ist nach dem Review leicht wieder zu entfernen.

PhpStorm kann TODOs auch nach Scope filtern: nur der aktuelle Branch, nur geänderte Dateien, nur bestimmte Verzeichnisse. In Magento-Projekten mit tausenden PHP-Dateien ist diese Filterung entscheidend, um nicht im Rauschen aller projektweit vorhandenen TODOs unterzugehen. Die Integration mit Changelists (nächster Abschnitt) erlaubt es, TODOs nur für die Dateien der aktuellen Changelist anzuzeigen.

<?php
// PhpStorm TODO markers — configurable under Settings > Editor > TODO
// Default recognized: TODO, FIXME, HACK, XXX

class CheckoutSessionPlugin
{
    // TODO: Extract to separate service class after SC-2045 is merged
    // FIXME: Race condition possible when two tabs submit simultaneously
    // REVIEW: Is this plugin order correct? Check plugin.xml di.xml priority
    public function afterGetQuote(
        \Magento\Checkout\Model\Session $subject,
        \Magento\Quote\Api\Data\CartInterface $result
    ): \Magento\Quote\Api\Data\CartInterface {
        // HACK: Workaround for Magento bug MGT-1234 — remove after 2.4.9
        if ($result->getItemsCount() === 0) {
            $this->logger->warning('Empty quote returned from session', [
                'customer_id' => $subject->getCustomerId(),
            ]);
        }
        return $result;
    }
}

// In PhpStorm: Alt+6 -> TODO panel shows all markers
// Filter: "Scope: Changed Files" -> only shows TODOs in current diff
// Custom marker regex: \bREVIEW\b.* -> highlighted in orange

6. Changelists: Änderungen gruppieren und Review vorbereiten

Changelists sind ein PhpStorm-spezifisches Feature, das in vielen Teams nicht bekannt ist: Anstatt alle lokalen Änderungen in einer einzigen uncommitted-Gruppe zu belassen, können Dateien in benannte Changelists aufgeteilt werden. Jede Changelist repräsentiert eine logische Einheit – etwa einen Bugfix, ein Feature oder ein Refactoring-Schritt. Neue Changelists werden im Commit-Dialog oder über das Changes-Panel (Alt+9) angelegt.

Für die Review-Vorbereitung ist das besonders nützlich, wenn ein Branch mehrere unabhängige Änderungen enthält. Statt den Reviewer mit einem gemischten Diff zu konfrontieren, können Changelists genutzt werden, um im Review-Gespräch gezielt auf Teilbereiche hinzuweisen. In PhpStorm kann man eine einzelne Changelist als Patch exportieren (Ctrl+Shift+A, dann "Create Patch from Changelist") und diesen Patch mit dem Team teilen – als Alternative zu einem komplexen PR.

Changelists haben auch einen praktischen Vorteil beim Committing: Man kann gezielt nur die Dateien einer Changelist committen, auch wenn andere Dateien bereits geändert sind. Das unterstützt atomare Commits und saubere Git-Historien – eine Voraussetzung für Reviews, bei denen jeder Commit eine eigenständige, überprüfbare Einheit darstellt.

<?php
// PhpStorm Changelists — organizing changes for review

// Changelist 1: "SC-1042 Fix EUR price rounding"
// Files: Model/Pricing/Calculator.php, Test/Unit/Model/Pricing/CalculatorTest.php

// Changelist 2: "Refactor: extract OrderValidator"
// Files: Model/Order/Validator.php (new), Service/OrderService.php (modified)

// Changelist 3: "REVIEW: WIP — do not commit"
// Files: scratch notes, debug traces

// In PhpStorm: Alt+9 -> Changes panel
// Right-click on file -> Move to Another Changelist
// To commit only one changelist: Commit dialog -> select changelist -> commit

// Create patch from changelist for sharing:
// Ctrl+Shift+A -> "Create Patch from Changelist" -> save .patch file
// Team member applies: VCS menu -> Apply Patch

// Shortcut to move file between changelists: Ctrl+Shift+M (default)

7. Kompletter Review-Workflow in PhpStorm

Ein vollständiger Review-Workflow in PhpStorm beginnt damit, den zu reviewenden Branch lokal auszuchecken: im Git-Panel den Branch wählen und "Checkout" – oder über die Branch-Auswahl unten rechts in der Status-Bar. PhpStorm aktualisiert automatisch alle Indizes. Dann öffnet man den Branch-Vergleich: Alt+9, Branch rechtsklicken, "Compare with Current".

Im nächsten Schritt geht man systematisch durch die geänderten Dateien: Doppelklick öffnet den Diff-Viewer. Für jede geänderte Datei nutzt man Annotate um ältere Zeilen einzuordnen, File History für komplexe Stellen und den TODO-Tracker für offene Punkte. Review-Notizen werden als temporäre TODO-Kommentare direkt im Code hinterlassen – sie erscheinen im TODO-Panel und können nach dem Review wieder entfernt werden.

Zum Abschluss des Reviews werden alle Review-TODOs aus dem Code entfernt, die Changelist des Reviewers geleert und der Branch wieder auf den eigenen Stand zurückgecheckt. Das Ergebnis des Reviews fließt in GitHub oder GitLab als Kommentare ein – dort, wo das Team die formalen Review-Entscheidungen trifft. PhpStorm ist dabei das Werkzeug für die inhaltliche Vorbereitung, nicht für die formale Entscheidung.

8. Vergleich: PhpStorm vs. GitHub-UI für Code Reviews

Beide Werkzeuge haben ihre Stärken. Die GitHub-Review-Oberfläche ist der gemeinsame Ort, wo formale Entscheidungen getroffen werden, Kommentare für alle sichtbar sind und der Review-Status dokumentiert wird. PhpStorm ist der Ort, wo die eigentliche inhaltliche Analyse stattfindet – mit vollem IDE-Kontext, statischer Analyse und Navigation.

9. Zusammenfassung

Code Reviews in PhpStorm vorzubereiten bedeutet, die inhaltliche Analyse in der IDE zu halten und nur die formale Entscheidung in GitHub oder GitLab zu treffen. Der Diff-Viewer bietet Side-by-Side-Vergleiche mit vollem IDE-Kontext. File History und "Show History for Selection" liefern das Warum hinter Änderungen. Die Annotate-Ansicht zeigt die Herkunft jeder Zeile und navigiert direkt in den zugehörigen Commit. Der TODO-Tracker macht offene Punkte sichtbar und erlaubt temporäre Review-Notizen direkt im Code. Changelists gruppieren Änderungen logisch und ermöglichen atomare Commits.

Der größte Gewinn liegt in der Kombination dieser Werkzeuge: Ein Review beginnt mit dem Branch-Vergleich, nutzt Annotate für Kontext, File History für Hintergründe und den TODO-Tracker für Nachverfolgung. Das macht Reviews gründlicher und weniger zeitaufwändig – weil der Reviewer nicht zwischen IDE, Terminal und Browser wechseln muss, um alle relevanten Informationen zusammenzubekommen.

10. FAQ: Code Reviews in PhpStorm