# Changelists und Änderungsgruppen verwenden

## Die Idee hinter Changelists

Git selbst kennt nur *einen* Index – die Staging Area, in der alle vorgemerkten Änderungen unabhängig von ihrem thematischen Zusammenhang landen. PhpStorm erweitert dieses Modell um eine eigene, rein lokale Organisationsebene: **Changelists**. Sie gruppieren geänderte, hinzugefügte oder gelöschte Dateien nach thematischer Zugehörigkeit, *bevor* sie überhaupt zu einem Commit werden.

Das ist besonders dann wertvoll, wenn du an mehreren Aufgaben gleichzeitig arbeitest, ohne für jede sofort einen eigenen Branch anzulegen – etwa ein kleiner Bugfix „nebenbei“, während du an einem größeren Feature arbeitest. Changelists sorgen dafür, dass du diese Änderungen getrennt betrachten, einzeln committen und nicht versehentlich miteinander vermischen kannst.

> **Wichtig:** Changelists sind eine reine PhpStorm-Funktion. Sie werden nicht in Git gespeichert und existieren nicht auf der Kommandozeile. Ein Kollege, der dasselbe Repository ausschließlich mit `git` bearbeitet, sieht davon nichts.

## Die Standard-Changelist „Default“

Nach dem Öffnen eines Projekts legt PhpStorm automatisch eine Changelist mit dem Namen *Default* an. Alle neuen und geänderten Dateien landen zunächst dort, sofern du nichts anderes konfigurierst. Für einfache, lineare Arbeit reicht diese eine Liste völlig aus – erst bei paralleler oder verschachtelter Arbeit lohnt sich eine bewusste Aufteilung.

## Eine neue Changelist erstellen

Im **Commit**-Werkzeugfenster (siehe vorheriges Kapitel) kannst du zusätzliche Changelists anlegen:

1. Rechtsklick in den Bereich der Changelists → **New Changelist…**
2. Namen und optional eine Beschreibung vergeben
3. Festlegen, ob die neue Liste sofort **aktiv** werden soll

Die *aktive* Changelist ist diejenige, der PhpStorm automatisch neu erkannte oder neu hinzugefügte Dateien zuordnet. Es existiert immer genau eine aktive Changelist.

## Dateien zwischen Changelists verschieben

Änderungen lassen sich jederzeit einer anderen Changelist zuordnen:

- Datei im Commit-Fenster per **Drag & Drop** in eine andere Liste ziehen
- Über das Kontextmenü **Move to Another Changelist…** wählen
- Mehrere Dateien gleichzeitig markieren und gemeinsam verschieben

Das ist der zentrale Arbeitsschritt: Statt Änderungen nur über den Dateibaum zu betrachten, sortierst du sie inhaltlich – etwa „Bugfix Login“, „Refactoring Repository-Klasse“ oder „Experimentelle Änderung, noch nicht fertig“.

## Commits aus einzelnen Changelists erzeugen

Beim Commit im PhpStorm-Werkzeugfenster wählst du gezielt **eine** Changelist als Grundlage aus:

1. Changelist markieren, deren Inhalt committet werden soll
2. Über das Kontextmenü **Commit** oder den Commit-Button im Fenster ausführen
3. Nur die Dateien dieser Liste werden Bestandteil des Commits – alle anderen Changelists bleiben unangetastet

So entstehen saubere, thematisch klare Commits, selbst wenn im Arbeitsverzeichnis gleichzeitig mehrere unabhängige Änderungen offen sind – ganz ohne `git add -p` oder manuelles Selektieren einzelner Zeilen bei jedem Commit erneut.

```mermaid
flowchart LR
    A["Arbeitsverzeichnis mit vielen Aenderungen"] --> B["Changelist Bugfix"]
    A --> C["Changelist Feature"]
    A --> D["Changelist Experiment"]
    B --> E["Commit 1"]
    C --> F["Commit 2"]
    D -.->|bleibt offen| D
```

## Inaktive Changelists und ihr Nutzen

Eine Changelist muss nicht sofort committet werden. Du kannst sie beliebig lange „liegen lassen“, während du an einer anderen Liste weiterarbeitest. Das ist hilfreich für:

- **Angefangene, aber unfertige Experimente**, die noch nicht reif für einen Commit sind
- **Vorbereitete Änderungen für einen späteren Zeitpunkt**, etwa nach Abschluss eines Reviews
- **Getrennte Verantwortlichkeiten**, wenn du absichtlich mehrere kleine, unabhängige Themen parallel im selben Arbeitsverzeichnis verfolgst

## Changelists und Diffs

Jede Changelist besitzt eine eigene Diff-Übersicht. Ein Doppelklick auf eine Datei innerhalb einer Changelist öffnet den Diff nur für diese Datei – unabhängig davon, wie viele andere Änderungen im Projekt insgesamt offen sind. Das erleichtert die Kontrolle vor dem Commit erheblich, weil du dich ausschließlich auf den relevanten Ausschnitt konzentrierst.

## Abgrenzung zu Shelving

Changelists solltest du nicht mit dem *Shelf* verwechseln, einem verwandten, aber eigenständigen PhpStorm-Werkzeug:

| Merkmal | Changelist | Shelf |
| --- | --- | --- |
| Zweck | Thematische Gruppierung offener Änderungen | Temporäres Zurücklegen von Änderungen |
| Sichtbarkeit im Arbeitsverzeichnis | Ja, Dateien bleiben geändert sichtbar | Nein, Änderungen werden aus dem Arbeitsverzeichnis entfernt |
| Git-Äquivalent | Kein direktes Äquivalent | Ähnlich zu `git stash` |
| Typischer Einsatz | Parallele Commits vorbereiten | Kurzfristig „Platz schaffen“, z. B. für einen dringenden Branch-Wechsel |

Wenn du also nur kurzfristig störende Änderungen aus dem Weg räumen möchtest, ist der Shelf das passendere Werkzeug; für die dauerhafte, inhaltliche Organisation mehrerer parallel offener Themen sind Changelists die richtige Wahl.

## Praktische Hinweise für den Alltag

- **Sprechende Namen verwenden:** Eine Changelist namens „Fix #482 Validierung“ ist hilfreicher als „Changelist 2“.
- **Nicht zu granular arbeiten:** Für die meisten Aufgaben reicht die Default-Liste. Zusätzliche Changelists lohnen sich erst bei echter Parallelität.
- **Vor dem Commit prüfen:** Kontrolliere immer, welche Changelist aktuell aktiv ist, bevor du neue Dateien erstellst – sonst landen sie versehentlich in der falschen Gruppe.
- **Kein Ersatz für Branches:** Changelists ersetzen keine Branch-Strategie. Sie helfen bei kurzfristiger, lokaler Organisation, nicht bei langfristig getrennter Entwicklung.

Mit diesem Werkzeug behältst du auch in unübersichtlichen Arbeitsphasen die Kontrolle darüber, *was* in welchen Commit einfließt – ein wichtiger Baustein für die im nächsten Abschnitt behandelte Zuordnung von IDE-Aktionen zu den entsprechenden Git-Befehlen auf der Kommandozeile.