# Das erste lokale Repository

Nun entsteht dein erstes Repository. Du initialisierst ein Projekt, prüfst seinen Zustand und verfolgst Dateien vom Arbeitsverzeichnis über die Staging Area bis zum Commit. Jeder Schritt wird sowohl mit Git-Befehlen als auch mit den entsprechenden Funktionen in PhpStorm durchgeführt.

# Ein Übungsprojekt anlegen

## Ziel dieses Abschnitts

Bevor du den ersten Befehl `git init` ausführst, brauchst du eine solide Ausgangsbasis: ein **Übungsprojekt**, an dem du die folgenden Kapitel gefahrlos durchspielen kannst. Dieses Projekt begleitet dich durch das gesamte vierte Kapitel – vom ersten Commit bis zum Vergleich von IDE- und Kommandozeilen-Workflow. Es lohnt sich daher, den Speicherort und die Struktur bewusst zu wählen, statt „irgendwo" schnell einen Ordner zu erstellen.

## Warum ein eigenes Testprojekt sinnvoll ist

Ein separates Übungsprojekt hat mehrere Vorteile gegenüber dem direkten Experimentieren in einem echten Arbeitsprojekt:

- **Risikofreiheit** – Fehlerhafte Commits, missglückte Resets oder gelöschte Dateien richten keinen Schaden an produktivem Code an.
- **Wiederholbarkeit** – Du kannst den Ordner jederzeit löschen und neu beginnen, wenn du dich „verrannt" hast.
- **Nachvollziehbarkeit** – Ein kleines, überschaubares Projekt macht `git log`, `git diff` und ähnliche Ausgaben leicht lesbar.
- **Übertragbarkeit** – Die hier erlernten Abläufe funktionieren identisch in jedem späteren PHP-Projekt.

## Den richtigen Speicherort wählen

Unter Windows 11 gibt es einige Fallstricke, die gerade Einsteiger häufig übersehen. Beachte folgende Punkte bereits *vor* dem Anlegen des Ordners:

### OneDrive vermeiden

Wenn dein Benutzerordner (`Dokumente`, `Desktop`) mit *OneDrive* synchronisiert wird, kann es zu Konflikten zwischen Git und dem Synchronisationsdienst kommen: OneDrive verändert Zeitstempel, sperrt Dateien kurzfristig oder synchronisiert das `.git`-Verzeichnis unnötig mit in die Cloud. Lege Übungsprojekte daher **außerhalb** synchronisierter Ordner ab, zum Beispiel direkt unter `C:\Users\<Name>\Projekte`.

### Kurze, einfache Pfade verwenden

Windows hatte historisch ein Limit von 260 Zeichen für Dateipfade. Auch wenn moderne Systeme lange Pfade unterstützen können (siehe Kapitel 2), ist es sinnvoll, tief verschachtelte Pfadstrukturen zu vermeiden. Ein Pfad wie

```
C:\Projekte\git-uebung
```

ist deutlich robuster als ein tief verschachtelter Pfad in einem OneDrive- oder Netzlaufwerk-Ordner.

### Keine Leerzeichen und Sonderzeichen im Ordnernamen

Leerzeichen, Umlaute oder Sonderzeichen im Projektpfad können in Kombination mit bestimmten Tools (Composer, PHPUnit, CI-Skripten) zu subtilen Fehlern führen. Verwende für den Ordnernamen ausschließlich Kleinbuchstaben, Ziffern und Bindestriche – ganz im Sinne späterer *Branch-Namenskonventionen* (siehe Kapitel 9).

## Projektstruktur planen

Für dieses Kapitel genügt ein sehr einfaches PHP-Projekt. Es soll klein bleiben, aber genügend Dateien enthalten, um sinnvolle Commits, Diffs und Umbenennungen zu demonstrieren:

```
git-uebung/
├── README.md
├── src/
│   └── Rechner.php
└── tests/
    └── RechnerTest.php
```

| Datei | Zweck |
|---|---|
| `README.md` | Kurzbeschreibung des Übungsprojekts |
| `src/Rechner.php` | Einfache PHP-Klasse als Beispielcode |
| `tests/RechnerTest.php` | Platzhalter für spätere Testübungen |

Diese Struktur reicht aus, um im weiteren Verlauf des Kapitels Dateien hinzuzufügen, zu ändern, umzubenennen und zu entfernen.

## Ordner und Dateien anlegen

Du kannst das Projekt sowohl über die Kommandozeile als auch über den Windows-Explorer anlegen. Für die Konsistenz mit späteren Kapiteln empfiehlt sich der Weg über *Git Bash* oder *PowerShell*.

### Variante 1: Git Bash

```bash
mkdir -p ~/Projekte/git-uebung/src
mkdir -p ~/Projekte/git-uebung/tests
cd ~/Projekte/git-uebung

echo "# Git-Übungsprojekt" > README.md
```

### Variante 2: PowerShell

```powershell
New-Item -ItemType Directory -Path "C:\Projekte\git-uebung\src" -Force
New-Item -ItemType Directory -Path "C:\Projekte\git-uebung\tests" -Force
Set-Location "C:\Projekte\git-uebung"

"# Git-Übungsprojekt" | Out-File -Encoding utf8 README.md
```

*Hinweis:* Achte in PowerShell auf die Kodierung. Git arbeitet intern mit UTF-8; Dateien, die PowerShell standardmäßig in UTF-16 speichert, können später zu unerwarteten Diffs führen (siehe Kapitel 29 zu `.gitattributes`).

### Beispielinhalt für `src/Rechner.php`

```php
<?php

declare(strict_types=1);

final class Rechner
{
    public function addieren(int $a, int $b): int
    {
        return $a + $b;
    }
}
```

### Beispielinhalt für `tests/RechnerTest.php`

```php
<?php

declare(strict_types=1);

// Platzhalter für spätere PHPUnit-Übungen.
```

Diese Dateien sind bewusst einfach gehalten – der Schwerpunkt dieses Kapitels liegt auf Git, nicht auf PHP-Architektur.

## Projekt in PhpStorm öffnen

Nachdem die Ordnerstruktur steht, öffnest du sie in PhpStorm, um beide Arbeitswege – Terminal und IDE – parallel nutzen zu können:

1. Starte PhpStorm und wähle **Datei → Öffnen…**.
2. Navigiere zum Ordner `git-uebung` und bestätige mit **OK**.
3. Wähle im folgenden Dialog **Als vertrauenswürdiges Projekt öffnen**, damit PhpStorm Indizierung und Codeanalyse ausführen darf.
4. Warte, bis die Indizierung abgeschlossen ist – erkennbar am Fortschrittsbalken unten rechts.

Zu diesem Zeitpunkt ist das Projekt noch **kein** Git-Repository. Das ändert sich erst im nächsten Abschnitt mit `git init` – bewusst als eigener, klar abgegrenzter Schritt.

## Checkliste vor dem nächsten Schritt

Bevor du weiterliest, sollten folgende Punkte erfüllt sein:

- [ ] Projektordner liegt außerhalb von OneDrive oder anderen Cloud-Synchronisationsordnern.
- [ ] Pfad ist kurz, enthält keine Leerzeichen oder Sonderzeichen.
- [ ] Ordnerstruktur mit `src/`, `tests/` und `README.md` ist vorhanden.
- [ ] Projekt ist in PhpStorm geöffnet und vollständig indiziert.
- [ ] Terminal (Git Bash oder PowerShell) ist im Projektordner geöffnet und einsatzbereit.

Mit dieser Grundlage bist du bereit für den eigentlichen Einstieg: die Initialisierung des Repositories mit `git init` und einem ersten Blick in das dabei entstehende `.git`-Verzeichnis.

# git init und das .git-Verzeichnis

## Der Moment, in dem ein Repository entsteht

Bevor Git eine einzige Datei verfolgen kann, muss es einen Ort haben, an dem es seine gesamte Buchführung ablegt. Genau das leistet der Befehl `git init`: Er verwandelt ein gewöhnliches Verzeichnis in ein *Git-Repository*, indem er darin ein verstecktes Unterverzeichnis namens `.git` anlegt. Dieses Verzeichnis ist keine Nebensächlichkeit – es *ist* das Repository. Alles, was du später über Commits, Branches, Remotes oder die Historie erfährst, ist letztlich nur eine strukturierte Sammlung von Dateien innerhalb dieses einen Ordners.

In diesem Abschnitt öffnest du das `.git`-Verzeichnis bewusst, statt es als Blackbox zu behandeln. Das schafft ein solides mentales Modell für alles Folgende.

### `git init` ausführen

Wechsle in Git Bash oder PowerShell in dein Übungsprojekt und führe aus:

```bash
cd C:\Users\DeinName\Projekte\uebungsprojekt
git init
```

Die Ausgabe sieht sinngemäß so aus:

```
Initialized empty Git repository in C:/Users/DeinName/Projekte/uebungsprojekt/.git/
```

Wichtig ist die Formulierung *„empty Git repository“*. Es wurden noch keine Dateien verfolgt, kein Commit erstellt – lediglich das Grundgerüst wurde angelegt. Ein Repository existiert also bereits, bevor überhaupt ein Commit gemacht wurde.

> **Hinweis:** Seit neueren Git-Versionen kannst du den initialen Branch direkt festlegen, etwa mit `git init -b main`. Das ist besonders unter Windows sinnvoll, da die Standardeinstellung je nach Konfiguration variieren kann (siehe Kapitel 2, Abschnitt *„Standard-Branch und Standard-Editor festlegen“*).

### Das `.git`-Verzeichnis sichtbar machen

Unter Windows 11 sind versteckte Dateien standardmäßig ausgeblendet. Um `.git` im Windows-Explorer zu sehen, aktiviere unter *Ansicht → Ausgeblendete Elemente* die Anzeige versteckter Ordner. Schneller geht es über die Kommandozeile:

```bash
ls -la
```

In PowerShell:

```powershell
Get-ChildItem -Force
```

Du solltest neben deinen Projektdateien einen Eintrag `.git` sehen – ein Verzeichnis, kein Symlink, keine spezielle Systemdatei. Das ist bewusst so gestaltet: Git funktioniert vollständig lokal und plattformunabhängig, ohne Betriebssystem-Dienste oder Datenbanken.

### Struktur des `.git`-Verzeichnisses

Wirf einen Blick in den Inhalt:

```bash
ls -la .git
```

Ein frisch initialisiertes Repository enthält typischerweise folgende Elemente:

| Element | Bedeutung |
|---|---|
| `HEAD` | Zeigt symbolisch auf den aktuell aktiven Branch |
| `config` | Repository-spezifische Konfiguration |
| `description` | Beschreibungstext, relevant für ältere Web-Oberflächen wie GitWeb |
| `hooks/` | Vorlagen für clientseitige und serverseitige Hooks |
| `info/` | Lokale Ausschlussregeln und Metainformationen |
| `objects/` | Der eigentliche Objektspeicher für Blobs, Trees und Commits |
| `refs/` | Referenzen auf Branches und Tags |

Zum aktuellen Zeitpunkt sind `objects/` und `refs/` noch weitgehend leer – schließlich wurde noch kein Inhalt committet. Das ändert sich, sobald du im nächsten Abschnitt deinen ersten Commit erstellst.

### `HEAD`: der Zeiger auf die Gegenwart

Öffne die Datei `HEAD` in einem Texteditor oder gib ihren Inhalt aus:

```bash
cat .git/HEAD
```

Die Ausgabe lautet üblicherweise:

```
ref: refs/heads/main
```

Das bedeutet: `HEAD` verweist nicht direkt auf einen Commit, sondern *symbolisch* auf einen Branch – konkret auf `refs/heads/main`. Da dieser Branch noch keinen Commit besitzt, existiert die referenzierte Datei `refs/heads/main` momentan noch gar nicht. Erst der erste Commit erzeugt sie. Dieses Verhalten ist ein gutes Beispiel dafür, dass Git mit *Verweisen auf Verweise* arbeitet – ein Konzept, das in Kapitel 23 vertieft wird.

### `config`: lokale Einstellungen

Die Datei `.git/config` enthält repository-spezifische Konfiguration, die Vorrang vor globalen Einstellungen hat:

```bash
cat .git/config
```

Direkt nach `git init` findest du dort meist nur einen minimalen Abschnitt:

```ini
[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    symlinks = false
    ignorecase = true
```

Bemerkenswert für Windows-Nutzer sind besonders `filemode = false` und `ignorecase = true` – beide spiegeln Eigenschaften des NTFS-Dateisystems wider und werden in Kapitel 29 im Detail erklärt.

### `objects/` und `refs/`: die beiden tragenden Säulen

Auch wenn diese Verzeichnisse aktuell leer wirken, lohnt sich ein kurzer Blick:

```bash
ls .git/objects
ls .git/refs
```

`objects/` wird später sämtliche Inhalte deines Projekts als inhaltsadressierte, unveränderliche Objekte speichern – Kapitel 22 widmet sich diesem *Content-Addressable Storage* ausführlich. `refs/` enthält die Unterordner `heads` und `tags`, die Branches beziehungsweise Tags als einfache Textdateien mit einem Commit-Hash abbilden.

### Visualisierung des Zusammenhangs

Das folgende Diagramm zeigt, wie die zentralen Bestandteile direkt nach `git init` zusammenhängen:

```mermaid
graph TD
    A["Arbeitsverzeichnis"] -->|git init| B[".git Verzeichnis"]
    B --> C["HEAD - verweist auf refs/heads/main"]
    B --> D["config - lokale Einstellungen"]
    B --> E["objects - noch leer"]
    B --> F["refs/heads - noch leer"]
    C -.->|symbolischer Verweis| F

    style B fill:#2f3b52,color:#ffffff
    style C fill:#3b5b3b,color:#ffffff
```

Der gestrichelte Pfeil verdeutlicht, dass `HEAD` lediglich *symbolisch* auf `refs/heads/main` zeigt – ein Ziel, das erst mit dem ersten Commit real wird.

### Ein bestehendes Verzeichnis erneut initialisieren

Führst du `git init` in einem Verzeichnis aus, das bereits ein Repository ist, richtet Git keinen Schaden an. Der Befehl ist *idempotent*: Bestehende Konfiguration, Objekte und Referenzen bleiben unverändert, Git meldet lediglich eine Reinitialisierung:

```
Reinitialized existing Git repository in ...
```

Das ist nützlich, wenn du beispielsweise versehentlich gelöschte Vorlagendateien in `hooks/` wiederherstellen möchtest, ohne die eigentliche Historie zu gefährden.

### Ein Repository wieder entfernen

Da das gesamte Repository ausschließlich im `.git`-Verzeichnis lebt, genügt dessen Löschung, um alle Versionsinformationen vollständig und unwiderruflich zu entfernen – deine eigentlichen Projektdateien bleiben dabei unberührt:

```powershell
Remove-Item -Recurse -Force .git
```

Dies solltest du nur bewusst und niemals in einem produktiven Projekt ohne Sicherung ausführen. Es demonstriert aber sehr eindringlich, dass Git keine externe Datenbank, sondern schlicht ein gut organisiertes Dateisystem nutzt.

### Blick in PhpStorm

Öffnest du das gerade initialisierte Verzeichnis in PhpStorm, erkennt die IDE das Repository automatisch anhand des `.git`-Ordners und aktiviert die VCS-Funktionen im Menü *Git*. PhpStorm blendet `.git` standardmäßig aus der Projektübersicht aus, da es sich um Metadaten und nicht um Projektinhalt handelt. Über *Einstellungen → Editor → File Types* lässt sich diese Ausblendung zwar anpassen, für den Alltag ist sie jedoch sinnvoll: Du arbeitest mit den komfortablen Werkzeugen der IDE, während das rohe `.git`-Verzeichnis unangetastet im Hintergrund verwaltet wird.

### Zwischenfazit

Mit `git init` hast du kein „Werkzeug gestartet“, sondern eine konkrete, inspizierbare Datenstruktur erzeugt. `HEAD`, `config`, `objects/` und `refs/` sind keine abstrakten Begriffe, sondern reale Dateien und Verzeichnisse, die du jederzeit öffnen kannst. Dieses Verständnis trägt dich durch den gesamten Kurs: Jeder spätere Befehl – ob `commit`, `branch`, `merge` oder `reset` – verändert am Ende nichts anderes als genau diese Dateien im `.git`-Verzeichnis.

Im nächsten Abschnitt nutzt du `git status`, um den aktuellen Zustand deines frisch initialisierten Repositorys systematisch zu lesen, bevor du die erste Datei zur Nachverfolgung vormerkst. 🗂️

# Den Zustand mit git status prüfen

## Den Zustand mit `git status` prüfen

Bevor du irgendeine Git-Operation ausführst – einen Commit erstellst, einen Branch wechselst oder Änderungen verwirfst – solltest du dir eine Frage stellen: *„In welchem Zustand befindet sich mein Repository gerade?“* Der Befehl `git status` ist die Antwort darauf. Er ist der wichtigste diagnostische Befehl in Git und sollte zur Selbstverständlichkeit werden, ähnlich wie ein Blick in den Rückspiegel vor dem Ausparken.

### Warum dieser Befehl so zentral ist

Git verändert nichts an deinen Dateien, ohne dass du es ausdrücklich anforderst. Das bedeutet aber auch: Es liegt an dir, jederzeit zu wissen, *was* sich im Arbeitsverzeichnis, in der Staging Area und im Repository befindet. `git status` liefert genau diese Momentaufnahme – ohne Nebenwirkungen, ohne Risiko. Er verändert niemals Dateien oder die Historie; du kannst ihn beliebig oft aufrufen.

> 💡 **Merksatz:** Im Zweifel `git status` ausführen – dieser Befehl kostet nichts und schützt vor teuren Fehlern.

### Grundlegender Aufruf

Im Übungsprojekt aus dem vorherigen Abschnitt reicht ein einfacher Aufruf:

```bash
git status
```

Direkt nach `git init`, wenn das Repository noch leer ist, liefert Git etwa folgende Ausgabe:

```text
Auf Branch main

Noch keine Commits

Nichts zu committen
```

Diese Ausgabe bestätigt drei wichtige Informationen gleichzeitig:

1. **Aktueller Branch** – hier `main`, der Standard-Branch.
2. **Commit-Historie** – es existiert noch kein einziger Commit.
3. **Arbeitsverzeichnis** – es gibt keine Änderungen, die Git registriert hat.

### Der typische Aufbau der Ausgabe

Sobald Dateien im Projekt vorhanden sind, wird die Ausgabe deutlich informativer. Angenommen, du hast eine neue Datei `index.php` erstellt:

```bash
git status
```

```text
Auf Branch main

Noch keine Commits

Unversionierte Dateien:
  (benutze "git add <Datei>..." zum Aufnehmen in das, was committet wird)
        index.php

nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien
(benutze "git add" zum Aufnehmen)
```

Diese Struktur begleitet dich durch den gesamten Kurs. Git gliedert die Ausgabe grundsätzlich in folgende Abschnitte:

| Abschnitt | Bedeutung |
|---|---|
| *Änderungen, die committet werden* | Inhalte in der Staging Area – bereit für den nächsten Commit |
| *Änderungen, die nicht zum Commit vorgemerkt sind* | Bereits verfolgte Dateien mit ungespeicherten Änderungen |
| *Unversionierte Dateien* | Dateien, die Git noch nicht kennt |

Besonders hilfreich: Git formuliert unter jeder Kategorie direkt den passenden Befehl, um den Zustand zu ändern. Diese Hinweistexte lohnt es sich, in den ersten Wochen bewusst zu lesen, statt sie zu überspringen.

### Den Zustand nach `git add` beobachten

Merke einen Teil der Datei nun mit `git add` vor:

```bash
git add index.php
git status
```

```text
Auf Branch main

Noch keine Commits

Änderungen, die committet werden:
  (benutze "git rm --cached <Datei>..." zum Entfernen aus der Staging-Area)
        neue Datei:     index.php
```

Die Datei ist jetzt aus der Kategorie *unversioniert* in die Kategorie *committen* gewandert. Genau dieses Verschieben zwischen den drei Bereichen – Arbeitsverzeichnis, Index und Repository – ist der Kern dessen, was `git status` sichtbar macht. Kapitel 5 vertieft dieses Modell; hier lernst du bereits, es praktisch zu beobachten.

### Zustand nach einem Commit und weiteren Änderungen

Nach dem ersten Commit (siehe folgender Abschnitt dieses Kapitels) ändert sich die Ausgabe erneut. Bearbeitest du `index.php` danach weiter, zeigt `git status` beispielsweise:

```text
Auf Branch main
Änderungen, die nicht zum Commit vorgemerkt sind:
  (benutze "git add <Datei>..." zum Aktualisieren, was committet werden soll)
  (benutze "git restore <Datei>..." zum Verwerfen von Änderungen im Arbeitsverzeichnis)
        geändert:       index.php

keine Änderungen zum Commit vorgemerkt (benutze "git add" und/oder "git commit -a")
```

Beachte den Unterschied zur vorherigen Ausgabe: Es fehlt der Hinweis *„Noch keine Commits“*, da bereits ein Commit existiert. Zudem erscheint jetzt die Kategorie *geändert* statt *neue Datei*, weil Git die Datei bereits aus einem früheren Commit kennt.

### Kurzform mit `git status -s`

Für den täglichen Gebrauch ist die ausführliche Ausgabe oft zu lang. Die Kurzform liefert dieselben Informationen kompakt:

```bash
git status -s
```

```text
 M index.php
?? notizen.txt
```

Die beiden Buchstaben links stehen jeweils für den **Index-Status** und den **Arbeitsverzeichnis-Status** einer Datei. Die wichtigsten Codes im Überblick:

| Code | Bedeutung |
|---|---|
| `??` | Unversionierte Datei |
| ` M` | Geändert, aber nicht vorgemerkt |
| `M ` | Geändert und vorgemerkt |
| `A ` | Neu hinzugefügt und vorgemerkt |
| `D ` | Gelöscht und vorgemerkt |
| `UU` | Merge-Konflikt in dieser Datei |

Diese Kurzform ist besonders nützlich, wenn du `git status` in eigene Aliase oder Skripte einbindest (siehe Kapitel 26).

### Branch- und Tracking-Informationen

`git status` zeigt zusätzlich an, wie dein lokaler Branch im Vergleich zu seinem Remote-Gegenstück steht – sobald ein Remote-Tracking existiert (Kapitel 13 und 14 behandeln dies ausführlich):

```text
Auf Branch main
Ihr Branch ist auf demselben Stand wie 'origin/main'.
```

Oder, falls du bereits lokale Commits hast, die noch nicht veröffentlicht wurden:

```text
Auf Branch main
Ihr Branch ist 2 Commits vor 'origin/main'.
  (benutze "git push", um lokale Commits zu veröffentlichen)
```

Diese Information bewahrt dich davor, versehentlich unveröffentlichte Arbeit zu verlieren oder zu überschreiben.

### `git status` in PhpStorm

PhpStorm zeigt denselben Zustand grafisch an, ohne dass du die Kommandozeile öffnen musst:

- Im **Projektbaum** werden Dateien farblich markiert: Blau für geänderte, Grün für neue (unversionierte) und Grau für ignorierte Dateien.
- Das **Commit-Werkzeugfenster** (`Alt` + `0`) listet alle geänderten und unversionierten Dateien strukturiert nach Changelists auf.
- Die **Statusleiste** unten zeigt den aktuellen Branch sowie die Anzahl ausstehender Änderungen.

```mermaid
flowchart LR
    A["Arbeitsverzeichnis"] -->|unversioniert / geändert| B["git status Ausgabe"]
    C["Staging Area / Index"] -->|vorgemerkt| B
    D["Letzter Commit"] -->|Vergleichsbasis| B
    B --> E["Entscheidung: add, restore, commit"]
```

Die farbliche Kennzeichnung in PhpStorm ist letztlich nichts anderes als eine visuelle Aufbereitung derselben Informationen, die `git status` textuell liefert. Wer beide Darstellungen kennt, kann flexibel zwischen grafischer Übersicht und präziser Kommandozeilenkontrolle wechseln.

### Praktische Gewohnheit etablieren

Für den weiteren Kursverlauf empfiehlt sich folgende Routine, die du ab jetzt konsequent anwenden solltest:

1. **Vor** jeder Aktion: `git status`, um den Ausgangszustand zu kennen.
2. **Nach** jeder Aktion (`add`, `commit`, `checkout`, `merge` etc.): erneut `git status`, um die Wirkung zu bestätigen.
3. Bei unklaren oder unerwarteten Meldungen: die Hinweistexte in der Ausgabe genau lesen, bevor du einen Befehl aus dem Gedächtnis ausführst.

Diese Disziplin verhindert die meisten Anfängerfehler, die in Abschnitt 1.8 bereits angesprochen wurden – etwa das versehentliche Committen unfertiger Dateien oder das Verwerfen von Änderungen, die eigentlich behalten werden sollten. `git status` ist damit nicht nur ein Informationsbefehl, sondern dein wichtigstes Sicherheitsnetz im gesamten Git-Alltag.

# Dateien mit git add vormerken

## Dateien mit `git add` vormerken

Nachdem du mit `git status` den Zustand deines Projekts eingeordnet hast, folgt der nächste logische Schritt: Du entscheidest bewusst, *welche* Änderungen Teil des nächsten Commits werden sollen. Genau das ist die Aufgabe von `git add` – dem Befehl, mit dem Dateien in die sogenannte *Staging Area* (auch *Index* genannt) aufgenommen werden.

### Vom Arbeitsverzeichnis in den Index

Git trennt bewusst zwischen dem, was in deinen Dateien steht, und dem, was tatsächlich im nächsten Commit landen soll. Diese Trennung ist kein technisches Detail, sondern eines der zentralen Konzepte von Git überhaupt – sie wird in Kapitel 5 vertieft. An dieser Stelle reicht folgendes Modell:

```mermaid
flowchart LR
    A["Arbeitsverzeichnis"] -->|git add| B["Staging Area Index"]
    B -->|git commit| C["Repository .git"]
```

`git add` kopiert also nicht einfach eine Datei, sondern merkt den *aktuellen Inhalt* dieser Datei für den nächsten Commit vor. Änderst du die Datei danach erneut, musst du sie erneut hinzufügen – ein Verhalten, das anfangs oft verwundert, aber sehr präzise Kontrolle ermöglicht.

### Der Grundbefehl

Am einfachsten fügst du eine einzelne Datei hinzu:

```bash
git add index.php
```

Mehrere Dateien lassen sich in einem Aufruf übergeben:

```bash
git add index.php composer.json README.md
```

Auch Wildcards funktionieren, sofern deine Shell sie unterstützt:

```bash
git add src/*.php
```

### Ganze Verzeichnisse und das Projekt komplett stagen

Für PHP-Projekte mit mehreren Verzeichnissen – etwa `src/`, `tests/` und `public/` – ist es oft praktischer, ganze Ordner vorzumerken:

```bash
git add src
git add tests
```

Willst du *alle* Änderungen im aktuellen Verzeichnis und dessen Unterverzeichnissen erfassen, verwendest du:

```bash
git add .
```

Wichtig: Der Punkt bezieht sich auf das aktuelle Arbeitsverzeichnis. Führst du den Befehl aus einem Unterordner aus, werden auch nur dessen Inhalte berücksichtigt – nicht das gesamte Repository.

### `git add .` vs. `git add -A` vs. `git add -u`

Diese drei Varianten werden häufig verwechselt, unterscheiden sich aber in einem entscheidenden Punkt: dem Umgang mit **gelöschten** Dateien.

| Befehl | Neue Dateien | Geänderte Dateien | Gelöschte Dateien | Bereich |
|---|---|---|---|---|
| `git add .` | ✔️ | ✔️ | ✔️ *(moderne Git-Versionen)* | Aktuelles Verzeichnis abwärts |
| `git add -A` | ✔️ | ✔️ | ✔️ | Gesamtes Repository |
| `git add -u` | ❌ | ✔️ | ✔️ | Gesamtes Repository, nur verfolgte Dateien |

*Hinweis:* Seit Git 2.x verhält sich `git add .` im gesamten Repository-Kontext praktisch identisch zu `git add -A`, sofern du dich im Wurzelverzeichnis befindest. In älteren Versionen gab es hier Unterschiede – solltest du auf ein Legacy-System stoßen, prüfe das Verhalten sicherheitshalber mit `git status`.

### Den Effekt kontrollieren

`git add` verändert nichts sichtbar an deinen Dateien – der Effekt zeigt sich ausschließlich im Status:

```bash
git status
```

Vor dem Staging:

```
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/Calculator.php
```

Nach `git add src/Calculator.php`:

```
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   src/Calculator.php
```

Diese farbliche und textuelle Unterscheidung zwischen *„Changes not staged“* und *„Changes to be committed“* ist eine der wichtigsten Orientierungshilfen im täglichen Git-Alltag.

### Ein praktisches Beispiel

Angenommen, du arbeitest an einem kleinen PHP-Projekt und hast folgende Änderungen vorliegen:

- eine neue Klasse `src/Calculator.php`
- eine geänderte `composer.json`
- eine gelöschte, nicht mehr benötigte Datei `legacy.php`

```bash
git status
```

```
Changes not staged for commit:
        modified:   composer.json
        deleted:    legacy.php

Untracked files:
        src/Calculator.php
```

Möchtest du **alles** in den nächsten Commit übernehmen:

```bash
git add -A
```

Möchtest du hingegen nur die neue Klasse vormerken und die anderen Änderungen bewusst für einen späteren, separaten Commit zurückhalten:

```bash
git add src/Calculator.php
```

`git status` zeigt danach exakt, was gestaged ist und was noch offen bleibt – ein zentrales Werkzeug, um Commits klein und thematisch sauber zu halten (siehe Kapitel 6).

### Ein häufiges Missverständnis

Ein weit verbreiteter Irrtum lautet: *„git add speichert meine Datei.“* Das ist nicht korrekt. `git add` verändert **nur den Index**, nicht das Repository. Erst `git commit` überführt den Inhalt des Index dauerhaft in die Historie. Bis dahin lässt sich jede Vormerkung problemlos wieder zurücknehmen – etwa mit:

```bash
git restore --staged <datei>
```

Diese Rücknahme wird in Kapitel 5 ausführlich behandelt; wichtig ist an dieser Stelle nur das Bewusstsein, dass Staging ein **reversibler Zwischenschritt** ist.

### Selektives Vorgehen als Gewohnheit

Auch wenn `git add -A` in vielen Situationen bequem erscheint, lohnt es sich, frühzeitig ein bewussteres Vorgehen einzuüben:

1. Änderungen mit `git status` und `git diff` sichten.
2. Nur thematisch zusammengehörige Dateien stagen.
3. Bei Bedarf mit `git status` erneut prüfen, ob wirklich nur das Gewünschte vorgemerkt ist.
4. Erst dann committen.

Diese Reihenfolge verhindert eines der häufigsten Anfängerprobleme: Commits, die versehentlich unfertigen Code, temporäre Debug-Ausgaben oder unabsichtlich geänderte Konfigurationsdateien enthalten.

### Ausblick

Der hier vorgestellte Grundmechanismus reicht für den Einstieg vollkommen aus. Im weiteren Kursverlauf – insbesondere in Kapitel 5 – vertiefst du das Staging deutlich: interaktives Hinzufügen einzelner Codeblöcke mit `git add -p`, das gezielte Entfernen aus dem Index sowie die Diagnose komplexer Zustände. Zunächst genügt es, den zentralen Grundsatz verinnerlicht zu haben:

> *Nichts gelangt in einen Commit, das nicht zuvor bewusst mit `git add` vorgemerkt wurde.*

Damit ist die Grundlage gelegt, um im nächsten Abschnitt den ersten echten Commit zu erstellen.

# Den ersten Commit erstellen

## Vom Index zum Commit

Nachdem du Dateien mit `git add` in die *Staging Area* aufgenommen hast, liegt der nächste Schritt nahe: Aus den vorgemerkten Änderungen wird ein **Commit** – ein unveränderlicher Schnappschuss deines Projekts zu einem bestimmten Zeitpunkt. Anders als der Name „Speichern“ vermuten lässt, erzeugt ein Commit keine einzelne Momentaufnahme einer Datei, sondern einen vollständigen, in sich geschlossenen Zustand des gesamten Repositorys.

Technisch betrachtet geschieht dabei Folgendes:

1. Git erstellt aus dem Inhalt der Staging Area einen sogenannten *Tree*, der die aktuelle Verzeichnisstruktur abbildet.
2. Ein neues *Commit-Objekt* verweist auf diesen Tree, auf den vorherigen Commit (den *Parent*) sowie auf Autor, Zeitstempel und Nachricht.
3. Der aktuelle Branch-Zeiger – meist `main` – wird auf dieses neue Commit-Objekt verschoben.

Diese internen Zusammenhänge vertiefst du später in Kapitel 22 „Git unter der Haube“. Für den praktischen Einstieg reicht es, den Commit als bewussten, benannten Kontrollpunkt in der Projektgeschichte zu verstehen.

---

## Voraussetzung: Ein saubere Staging Area

Bevor du committest, lohnt sich ein kurzer Blick mit `git status`:

```bash
git status
```

```text
Auf Branch main

Zum Commit vorgemerkte Änderungen:
  (benutze "git restore --staged <Datei>..." zum Entfernen aus der Staging Area)
        neue Datei:     README.md
```

Nur was hier unter *„Zum Commit vorgemerkte Änderungen“* aufgeführt ist, wird tatsächlich Teil des Commits. Dateien im Arbeitsverzeichnis, die noch nicht mit `git add` vorgemerkt wurden, bleiben unberührt – ein wichtiger Sicherheitsmechanismus, den du bereits in Kapitel 5 kennengelernt hast.

---

## Den Commit erstellen

### Mit einer kurzen Nachricht direkt in der Kommandozeile

Der schnellste und im Alltag häufigste Weg verwendet die Option `-m`:

```bash
git commit -m "Initiale Projektstruktur hinzufügen"
```

Git bestätigt den Vorgang mit einer kurzen Zusammenfassung:

```text
[main (Root-Commit) a1b2c3d] Initiale Projektstruktur hinzufügen
 1 file changed, 12 insertions(+)
 create mode 100644 README.md
```

Diese Ausgabe enthält bereits drei wichtige Informationen:

- den **Branch**, auf dem der Commit liegt (`main`),
- den Hinweis **Root-Commit**, da es sich um den allerersten Commit im Repository handelt,
- die ersten Zeichen des **Commit-Hashes** (`a1b2c3d`), über den sich der Commit später eindeutig identifizieren lässt.

### Mit dem konfigurierten Editor

Lässt du `-m` weg, öffnet Git den in Kapitel 2 festgelegten Standard-Editor:

```bash
git commit
```

Das ist besonders bei umfangreicheren Änderungen sinnvoll, da sich im Editor eine mehrzeilige Nachricht mit Betreff, Leerzeile und ausführlicher Beschreibung formulieren lässt:

```text
Formular zur Benutzerregistrierung hinzufügen

Implementiert Validierung für E-Mail und Passwort.
Bezieht sich auf Issue #12.
```

Speicherst du die Datei und schließt den Editor, wird der Commit erstellt. Ein leerer Editorinhalt bricht den Vorgang dagegen ab – eine bewusste Schutzmaßnahme gegen Commits ohne Nachricht.

> 💡 **Hinweis für Windows 11:** Falls sich kein Editor öffnet oder Git Bash mit einer Fehlermeldung wie `error: cannot spawn` reagiert, wurde der Editor in `core.editor` vermutlich falsch konfiguriert. Kapitel 2 zeigt, wie du das korrigierst.

---

## Anforderungen an eine gute Commit-Nachricht

Eine ausführliche Behandlung von Commit-Konventionen folgt in Kapitel 6. Für den Einstieg gelten drei einfache Regeln:

| Regel | Beispiel |
|---|---|
| Im Imperativ formulieren | „Login-Validierung hinzufügen“ statt „Habe Validierung hinzugefügt“ |
| Kurz und aussagekräftig | Erste Zeile idealerweise unter 50–72 Zeichen |
| Eine Änderung, eine Absicht | Nicht mehrere unabhängige Themen in einem Commit vermischen |

Eine unpräzise Nachricht wie `"update"` oder `"fix"` mag im Moment praktisch erscheinen, erschwert aber jede spätere Auswertung mit `git log` oder `git blame` erheblich.

---

## Wer steckt hinter einem Commit?

Jeder Commit speichert automatisch Autor und Zeitstempel – basierend auf den Werten, die du in Kapitel 2 mit `git config` gesetzt hast:

```bash
git config user.name
git config user.email
```

Diese Angaben lassen sich für einen einzelnen Commit auch gezielt überschreiben, etwa bei Pair-Programming oder Testcommits:

```bash
git commit -m "Testcommit" --author="Testperson <test@example.com>"
```

Der Unterschied zwischen *Autor* und *Committer* – relevant etwa bei Rebase oder Cherry-Pick – wird in Kapitel 6 vertieft.

---

## Den Commit überprüfen

Direkt nach dem Erstellen solltest du dir zur Gewohnheit machen, das Ergebnis zu kontrollieren.

**Historie ansehen:**

```bash
git log
```

```text
commit a1b2c3d4e5f67890abcdef1234567890abcdef1
Author: Max Mustermann <max@example.com>
Date:   Mon Jan 8 10:15:32 2025 +0100

    Initiale Projektstruktur hinzufügen
```

**Inhalt des Commits im Detail prüfen:**

```bash
git show a1b2c3d
```

Dieser Befehl zeigt sowohl die Metadaten als auch den vollständigen Diff der im Commit enthaltenen Änderungen – nützlich, um zu bestätigen, dass tatsächlich nur die gewünschten Anpassungen erfasst wurden.

**Arbeitsverzeichnis erneut prüfen:**

```bash
git status
```

```text
Auf Branch main
nichts zu committen, Arbeitsverzeichnis unverändert
```

Diese Meldung zeigt an, dass alle vorgemerkten Änderungen erfolgreich in die Historie übernommen wurden.

---

## Typische Stolperfallen

- **„Nothing to commit“ trotz Änderungen:** Die Dateien wurden verändert, aber nicht mit `git add` vorgemerkt. Ein Blick auf `git status` klärt sofort, ob Änderungen noch als *„nicht vorgemerkt“* geführt werden.
- **Leerer Commit gewünscht:** In seltenen Fällen – etwa um einen CI-Lauf auszulösen – lässt sich ein Commit ohne Inhaltsänderung mit `git commit --allow-empty -m "..."` erzwingen.
- **Falsche Nachricht direkt nach dem Commit:** Kein Grund zur Sorge – Kapitel 6 zeigt, wie sich der letzte Commit mit `git commit --amend` sauber korrigieren lässt, solange er noch nicht veröffentlicht wurde.
- **Zeilenenden-Warnungen unter Windows:** Meldungen wie `warning: LF will be replaced by CRLF` sind normal und resultieren aus der in Kapitel 2 behandelten `core.autocrlf`-Konfiguration. Sie verhindern den Commit nicht.

---

## Ausblick

Damit besitzt dein Repository seinen ersten dokumentierten Zustand. Im weiteren Verlauf dieses Kapitels lernst du, wie sich diese Historie mit `git log` gezielt lesen lässt, wie Änderungen zwischen Commits mit `git diff` sichtbar werden – und wie sich exakt derselbe Ablauf komfortabel über die Commit-Oberfläche von PhpStorm abbilden lässt, ohne die Kommandozeile zu verlassen.

# Commit-Historie mit git log lesen

## Commit-Historie mit git log lesen

Ein Repository ist nur so wertvoll wie die Geschichte, die es erzählt. Mit jedem Commit wächst ein Protokoll, das dokumentiert, *wer* *wann* *welche* Änderung vorgenommen hat und *warum*. Der Befehl `git log` ist das zentrale Werkzeug, um dieses Protokoll zu lesen – und wer ihn beherrscht, kann sich in jedem Projekt schnell orientieren, unabhängig davon, wie alt oder komplex es ist.

### Die Grundform verstehen

Ohne weitere Optionen zeigt `git log` die Historie in umgekehrter chronologischer Reihenfolge an – der neueste Commit steht oben:

```bash
git log
```

Die Ausgabe sieht typischerweise so aus:

```
commit 8f3c1a9b2e4d5f6a7b8c9d0e1f2a3b4c5d6e7f8a
Author: Anna Beispiel <anna@beispiel.de>
Date:   Mon Mar 4 14:22:07 2024 +0100

    Formular-Validierung hinzugefügt

commit 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b
Author: Anna Beispiel <anna@beispiel.de>
Date:   Mon Mar 4 13:05:41 2024 +0100

    Erste Projektstruktur angelegt
```

Jeder Eintrag besteht aus vier festen Bestandteilen:

- **Commit-Hash** – die eindeutige, vierzig Zeichen lange SHA-1-Kennung des Commits.
- **Author** – Name und E-Mail-Adresse der Person, die den Inhalt erstellt hat.
- **Date** – Zeitstempel inklusive Zeitzone.
- **Commit-Nachricht** – der erklärende Text, den du beim Commit vergeben hast.

Da lange Hashes unhandlich sind, genügt fast immer ein *eindeutiges Präfix* von sechs bis acht Zeichen, um einen Commit später zu referenzieren.

### Kompakte Ansichten mit --oneline

Bei größeren Historien wird die ausführliche Ansicht schnell unübersichtlich. Die Option `--oneline` reduziert jeden Commit auf eine einzige Zeile:

```bash
git log --oneline
```

```
8f3c1a9 Formular-Validierung hinzugefügt
1a2b3c4 Erste Projektstruktur angelegt
```

Diese verkürzte Form ist der Standard für einen schnellen Überblick und wird häufig mit weiteren Optionen kombiniert.

### Den Verlauf begrenzen

Nicht immer wird die gesamte Historie benötigt. Mit `-n` beschränkst du die Ausgabe auf eine bestimmte Anzahl von Commits:

```bash
git log -n 5
```

Alternativ lässt sich der Zeitraum eingrenzen:

```bash
git log --since="2 weeks ago"
git log --until="2024-03-01"
git log --since="2024-01-01" --until="2024-02-01"
```

### Nach Inhalt und Person filtern

`git log` erlaubt gezielte Suchen innerhalb der Historie, ohne dass du die Ausgabe manuell durchsuchen musst.

| Ziel | Befehl |
|---|---|
| Nach Autor filtern | `git log --author="Anna"` |
| Nach Nachrichtentext suchen | `git log --grep="Validierung"` |
| Commits einer Datei anzeigen | `git log -- pfad/zur/datei.php` |
| Nur Merge-Commits anzeigen | `git log --merges` |
| Merge-Commits ausblenden | `git log --no-merges` |

Diese Filter lassen sich beliebig kombinieren, etwa um alle Commits einer bestimmten Person innerhalb eines Zeitraums zu einer bestimmten Datei zu finden.

### Änderungen direkt mitanzeigen

Manchmal reicht die Nachricht allein nicht aus – du willst sehen, *was* sich tatsächlich geändert hat.

- `git log -p` zeigt zu jedem Commit den vollständigen Patch (Diff) an.
- `git log --stat` zeigt stattdessen eine kompakte Statistik mit geänderten Dateien und der Anzahl hinzugefügter beziehungsweise entfernter Zeilen.

```bash
git log --stat
```

```
8f3c1a9 Formular-Validierung hinzugefügt
 src/Validator.php | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
```

Diese Übersicht eignet sich gut, um schnell einzuschätzen, wie umfangreich ein Commit war, ohne den gesamten Patch lesen zu müssen.

### Eigene Formate mit --pretty und --format

Für individuelle Ansichten bietet Git das Format `--pretty=format:"…"`, mit dem du festlegst, welche Informationen in welcher Reihenfolge erscheinen.

```bash
git log --pretty=format:"%h – %an, %ar : %s"
```

```
8f3c1a9 – Anna Beispiel, 2 hours ago : Formular-Validierung hinzugefügt
1a2b3c4 – Anna Beispiel, 3 hours ago : Erste Projektstruktur angelegt
```

Die wichtigsten Platzhalter:

| Platzhalter | Bedeutung |
|---|---|
| `%h` | Kurzer Commit-Hash |
| `%H` | Vollständiger Commit-Hash |
| `%an` | Autorenname |
| `%ae` | Autoren-E-Mail |
| `%ad` / `%ar` | Datum absolut / relativ |
| `%s` | Betreffzeile der Commit-Nachricht |

Da solche Formate schnell lang werden, lohnt es sich, sie später als Git-Alias zu speichern – ein Thema, das in einem eigenen Kapitel zu fortgeschrittenen Werkzeugen vertieft wird.

### Verzweigungen sichtbar machen

Sobald ein Projekt mehrere Branches enthält, hilft eine grafische Darstellung, Zusammenhänge zu erkennen:

```bash
git log --oneline --graph --all
```

```
* 8f3c1a9 (HEAD -> main) Formular-Validierung hinzugefügt
* 1a2b3c4 Erste Projektstruktur angelegt
```

Die Option `--graph` zeichnet die Commit-Struktur mit Zeichen wie `*`, `|` und `\`, während `--all` sämtliche Branches statt nur den aktuellen einbezieht. In einem reinen lokalen Repository mit nur einem Branch wirkt diese Ansicht noch schlicht – ihr Nutzen zeigt sich erst, sobald mehrere Branches parallel existieren, wie in einem späteren Kapitel ausführlich behandelt wird.

### Relative Referenzen im Log verwenden

Anstelle vollständiger Hashes kannst du Commits relativ zum aktuellen Stand ansprechen:

```bash
git log HEAD~1
git log HEAD~2..HEAD
```

`HEAD~1` bezeichnet den Elternteil des aktuellen Commits, `HEAD~2` den Großelternteil und so weiter. Der Bereichsoperator `..` zeigt alle Commits zwischen zwei Punkten an – eine Notation, die in späteren Kapiteln zu Branches und Vergleichen regelmäßig wiederkehrt.

### Ausblick: Historie in PhpStorm

Alles, was hier über die Kommandozeile erarbeitet wurde, lässt sich auch grafisch im **Git-Werkzeugfenster** von PhpStorm nachvollziehen – inklusive Filterung, Diff-Ansicht und Graphdarstellung per Mausklick. Da dieser Kurs bewusst Kommandozeile und IDE parallel vermittelt, wird der identische Workflow am Ende dieses Kapitels vollständig in PhpStorm wiederholt.

### Checkliste für den Alltag

- 📜 `git log --oneline` für einen schnellen Überblick.
- 🔍 `git log --grep` oder `--author`, um gezielt zu suchen.
- 📊 `git log --stat`, um den Umfang von Änderungen einzuschätzen.
- 🌳 `git log --graph --all`, sobald mehrere Branches im Spiel sind.
- ✂️ `HEAD~n`, um relativ zum aktuellen Stand zu navigieren.

Wer diese Grundtechniken verinnerlicht, verfügt über das Handwerkszeug, um sich in jedem – auch fremden – Git-Repository zügig zurechtzufinden, bevor im nächsten Abschnitt mit `git diff` der inhaltliche Vergleich von Änderungen im Detail folgt.

# Änderungen mit git diff untersuchen

## Änderungen mit `git diff` untersuchen

Ein Commit fasst nur zusammen, *was* sich verändert hat – doch bevor du überhaupt vormerkst oder committest, willst du genau wissen, *welche* Zeilen betroffen sind. Genau dafür ist `git diff` gedacht: Es macht Unterschiede zwischen zwei Zuständen deines Projekts sichtbar, ohne selbst irgendetwas zu verändern. `git diff` ist damit ein reines *Lesewerkzeug* – ideal, um vor jedem `git add` und jedem Commit einen letzten Kontrollblick zu werfen.

### Drei Bereiche, drei Vergleiche

Erinnere dich an das Drei-Bereiche-Modell aus dem vorherigen Kapitel: Arbeitsverzeichnis, Index (Staging Area) und Repository. `git diff` vergleicht standardmäßig genau zwei dieser Bereiche – je nach Aufruf unterschiedliche.

| Befehl | Vergleicht | Beantwortet die Frage |
|---|---|---|
| `git diff` | Arbeitsverzeichnis ↔ Index | „Was habe ich verändert, aber noch nicht vorgemerkt?“ |
| `git diff --staged` (oder `--cached`) | Index ↔ letzter Commit | „Was würde ein Commit jetzt genau festhalten?“ |
| `git diff HEAD` | Arbeitsverzeichnis ↔ letzter Commit | „Was unterscheidet sich insgesamt vom letzten Commit – egal ob vorgemerkt oder nicht?“ |

Diese Unterscheidung ist der Schlüssel zum Verständnis: `git status` sagt dir nur, *dass* etwas verändert wurde, `git diff` zeigt dir *wie*.

### Der Standardfall: Arbeitsverzeichnis gegen Index

Nimm an, du hast eine Datei `index.php` bearbeitet, aber noch nichts mit `git add` vorgemerkt:

```bash
git diff
```

Die Ausgabe könnte so aussehen:

```diff
diff --git a/index.php b/index.php
index e69de29..f2c1a3d 100644
--- a/index.php
+++ b/index.php
@@ -1,3 +1,5 @@
 <?php
-echo "Hallo Welt";
+echo "Hallo, Git!";
+
+// Neue Zeile für die Begrüßung
```

Diese Ausgabe folgt dem sogenannten **Unified-Diff-Format**, das nicht nur Git, sondern auch viele andere Werkzeuge verwenden. Es lohnt sich, jeden Bestandteil einmal genau zu lesen:

- **`diff --git a/... b/...`** – kennzeichnet die verglichenen Dateien; `a` steht für die alte, `b` für die neue Version.
- **`index e69de29..f2c1a3d`** – zeigt die betroffenen Objekt-Hashes (dazu mehr im Kapitel über Git-Interna).
- **`---` / `+++`** – markieren die alte bzw. neue Dateiversion.
- **`@@ -1,3 +1,5 @@`** – der sogenannte *Hunk-Header*. Er bedeutet: „Ab Zeile 1 wurden in der alten Datei 3 Zeilen, in der neuen Datei 5 Zeilen betrachtet.“
- **Zeilen mit `-`** wurden entfernt, Zeilen mit **`+`** wurden hinzugefügt, unveränderte Zeilen erscheinen ohne Präfix als Kontext.

Diese Kontextzeilen sind wichtig: Sie helfen dir, die Änderung im umgebenden Code einzuordnen, ohne die ganze Datei öffnen zu müssen.

### Vorgemerkte Änderungen prüfen: `--staged`

Sobald du `git add` ausgeführt hast, zeigt der einfache `git diff` nichts mehr an – die Änderung liegt jetzt im Index, nicht mehr nur im Arbeitsverzeichnis. Um zu sehen, was genau ein Commit übernehmen würde, verwendest du:

```bash
git diff --staged
```

`--cached` ist ein reines Synonym und liefert dasselbe Ergebnis:

```bash
git diff --cached
```

Diese Unterscheidung zwischen *unstaged* und *staged* Diffs ist besonders bei selektivem Staging wertvoll (siehe Kapitel 5), wenn du bewusst nur einen Teil deiner Änderungen committen möchtest.

### Alles auf einen Blick: `git diff HEAD`

Willst du unabhängig vom Staging-Status wissen, was sich seit dem letzten Commit insgesamt verändert hat – egal ob vorgemerkt oder nicht – hilft:

```bash
git diff HEAD
```

`HEAD` ist dabei ein Zeiger auf den aktuellen Commit, mit dem du später noch viel intensiver arbeiten wirst.

### Einzelne Dateien oder Verzeichnisse vergleichen

`git diff` lässt sich immer auf konkrete Pfade einschränken. Das ist besonders bei größeren Projekten hilfreich, um den Fokus zu behalten:

```bash
git diff index.php
git diff src/
```

Mehrere Pfade lassen sich einfach aneinanderhängen:

```bash
git diff README.md composer.json
```

### Kompakte Übersichten statt vollständiger Diffs

Manchmal willst du nicht jede Zeile sehen, sondern nur wissen, *welche* Dateien betroffen sind und *wie stark*:

```bash
git diff --stat
```

```
 index.php | 4 ++--
 README.md | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)
```

Für eine reine Auflistung der geänderten Dateinamen eignen sich:

```bash
git diff --name-only
git diff --name-status
```

`--name-status` ergänzt zusätzlich ein Kürzel wie `M` (modified), `A` (added) oder `D` (deleted) – praktisch für Skripte oder einen schnellen Überblick.

### Wortweise statt zeilenweise vergleichen

Bei Prosatexten, Dokumentation oder Konfigurationsdateien ist eine zeilenbasierte Darstellung oft unübersichtlich, wenn nur ein einzelnes Wort geändert wurde. Hier hilft der Wortmodus:

```bash
git diff --word-diff
```

Er markiert nicht ganze Zeilen, sondern einzelne geänderte Wortfolgen mit `[-alt-]` und `{+neu+}` – deutlich präziser für kleinteilige Textänderungen.

### Vorausblick: Commits und Branches vergleichen

`git diff` beschränkt sich nicht auf die drei lokalen Bereiche. Es lassen sich ebenso zwei beliebige Commits, Branches oder Tags gegenüberstellen, etwa mit:

```bash
git diff main feature/login
```

Diese Fähigkeit wird im Kapitel „Historie lesen, durchsuchen und vergleichen“ ausführlich vertieft – an dieser Stelle reicht es, zu wissen, dass `git diff` dafür dieselbe Syntax und dieselbe Ausgabe-Logik verwendet wie beim Vergleich von Arbeitsverzeichnis und Index.

### Diff-Ausgaben besser lesbar machen

Auf vielen Windows-Terminals lohnt es sich, farbige Ausgaben zu aktivieren, falls sie nicht bereits standardmäßig aktiv sind:

```bash
git config --global color.diff auto
```

Für sehr lange Diffs kann zusätzlich ein Pager wie `less` hilfreich sein, den Git unter Windows über Git Bash automatisch mitbringt. Falls die Ausgabe im Terminal umbricht oder unübersichtlich wirkt, ist das ein guter Moment, um zur grafischen Diff-Ansicht in PhpStorm zu wechseln – dort erscheinen alte und neue Version übersichtlich nebeneinander, farblich hervorgehoben und mit Navigationspfeilen zwischen den Änderungsblöcken. Wie dieser Workflow konkret aussieht, zeigt der letzte Abschnitt dieses Kapitels.

### Zusammenfassung

`git diff` ist dein wichtigstes Werkzeug, um Änderungen *vor* dem Staging und *vor* dem Commit kritisch zu prüfen. Die zentrale Faustregel lautet:

- **Kein Argument** → Arbeitsverzeichnis gegen Index (unstaged Änderungen).
- **`--staged`/`--cached`** → Index gegen letzten Commit (was der nächste Commit enthält).
- **`HEAD`** → Arbeitsverzeichnis gegen letzten Commit (alles zusammen).

Wer diese drei Varianten sicher unterscheidet, vermeidet eine der häufigsten Anfängerverwirrungen in Git: die Frage, *warum* eine erwartete Änderung im Diff plötzlich nicht mehr auftaucht, obwohl die Datei sichtbar verändert wurde. 🔍

# Dateien umbenennen und verschieben

## Dateien umbenennen und verschieben

Anders als viele Entwickler zunächst erwarten, speichert Git *keine* expliziten Umbenennungsinformationen. Es gibt in der internen Datenstruktur kein Attribut „diese Datei wurde umbenannt“. Git arbeitet stattdessen mit Snapshots ganzer Verzeichnisbäume und **erkennt** Umbenennungen nachträglich, indem es Dateiinhalte zwischen zwei Commits auf Ähnlichkeit vergleicht. Dieses Verständnis ist wichtig, um das Verhalten von `git status`, `git diff` und `git log` bei verschobenen oder umbenannten Dateien richtig einzuordnen.

### Der Komfortbefehl `git mv`

Für den Alltag stellt Git den Befehl `git mv` bereit, der zwei Schritte in einem einzigen Kommando zusammenfasst: das physische Umbenennen im Dateisystem und das Vormerken der Änderung im Index.

```bash
git mv alt.txt neu.txt
```

Dieser Aufruf entspricht exakt der folgenden Sequenz:

```bash
mv alt.txt neu.txt
git add alt.txt neu.txt
```

`git mv` ist also reine Bequemlichkeit – kein eigenständiger Git-Mechanismus. Ein Blick auf `git status` nach einem `git mv` zeigt den erwarteten Zustand:

```
renamed:    alt.txt -> neu.txt
```

### Manuelles Umbenennen

Wer eine Datei über den Windows-Explorer, PhpStorm oder ein beliebiges anderes Werkzeug umbenennt, erzielt am Ende dasselbe Ergebnis. Git registriert zunächst zwei getrennte Änderungen:

```
deleted:    alt.txt
new file:   neu.txt
```

Erst beim Erstellen des Commits – beziehungsweise beim Anzeigen von `git status` mit Ähnlichkeitserkennung – interpretiert Git diese Kombination als Umbenennung. Sofern der Inhalt der Datei weitgehend unverändert bleibt, ist es **funktional gleichwertig**, ob `git mv` verwendet wird oder Löschen und Neuanlegen manuell erfolgen. Für die Übersichtlichkeit im Arbeitsalltag ist `git mv` jedoch vorzuziehen, da es Missverständnisse vermeidet und die Absicht sofort klar kommuniziert.

### Wie Git Umbenennungen erkennt

Die Erkennung basiert auf einem Ähnlichkeitsvergleich, keiner festen Zuordnung. Git betrachtet eine gelöschte und eine neu hinzugekommene Datei als „umbenannt“, wenn ihr Inhalt zu einem konfigurierbaren Prozentsatz übereinstimmt. Der Standardwert liegt bei **50 %**.

```bash
git status -M          # zeigt Umbenennungen mit Standardschwelle
git diff -M50%          # explizite Schwelle angeben
git log --follow neu.txt
```

Der Parameter `--follow` ist besonders wertvoll: Er sorgt dafür, dass `git log` die Historie einer Datei über Umbenennungen hinweg verfolgt, statt an dem Punkt zu stoppen, an dem der alte Dateiname verschwindet.

> **Hinweis:** Wird eine Datei beim Umbenennen zusätzlich stark inhaltlich verändert, kann Git die Beziehung nicht mehr erkennen. In diesem Fall erscheinen zwei unabhängige Einträge – eine Löschung und eine Neuanlage – und die Historie „reißt“ an dieser Stelle ab.

### Dateien in andere Verzeichnisse verschieben

Das Prinzip gilt unverändert für Verschiebungen zwischen Verzeichnissen:

```bash
git mv src/Helper.php src/Utils/Helper.php
```

Auch hier merkt Git die neue Position im Index vor. Fehlt das Zielverzeichnis, muss es zuvor angelegt werden, da Git – im Gegensatz zu vielen anderen Werkzeugen – keine leeren Verzeichnisse verwaltet, sondern ausschließlich Dateien.

### Umbenennungen als eigenständige Commits

Für eine nachvollziehbare Projektgeschichte empfiehlt es sich, Umbenennungen **getrennt** von inhaltlichen Änderungen zu committen:

```bash
git mv OldClassName.php NewClassName.php
git commit -m "refactor: Klasse in NewClassName umbenennen"
```

Werden Umbenennung und Codeänderung im selben Commit vermischt, sinkt die Wahrscheinlichkeit einer korrekten automatischen Erkennung erheblich, und spätere Reviews sowie `git blame`-Analysen werden unnötig erschwert.

### Kontrolle nach dem Umbenennen

Zur Absicherung sollte der Zustand vor dem Commit stets überprüft werden:

```bash
git status
git diff --staged
```

`git status` bestätigt die erkannte Umbenennung, während `git diff --staged` zeigt, ob neben dem neuen Namen unbeabsichtigt auch Inhalte verändert wurden.

### Ausblick

Der hier beschriebene Kommandozeilen-Workflow bildet die Grundlage. Wie sich Umbenennungen und Verschiebungen komfortabel und mit visueller Rückmeldung direkt in PhpStorm durchführen lassen, zeigt der folgende Abschnitt *„Derselbe Workflow in PhpStorm“* 🧭 – inklusive automatischer Referenzanpassung im PHP-Code, die die IDE zusätzlich übernimmt.

# Dateien aus Git entfernen

Das Löschen einer Datei ist in Git ein eigenständiger, protokollierter Vorgang – kein Nebeneffekt des Dateisystems. Wer eine Datei einfach im Explorer oder in PhpStorm löscht, hat Git davon zunächst nichts mitgeteilt. Dieser Abschnitt zeigt, wie Löschvorgänge korrekt vorgemerkt, committet und in unterschiedlichen Varianten durchgeführt werden.

### Löschen im Dateisystem versus Löschen in Git

Wenn du eine Datei manuell löschst, meldet `git status` sie als *geänderte, aber nicht vorgemerkte* Datei:

```bash
del beispiel.txt
git status
```

```
Changes not staged for commit:
  deleted:    beispiel.txt
```

Git erkennt zwar, dass die Datei fehlt, hat die Löschung aber noch nicht in den Index übernommen. Erst ein zusätzlicher `git add` – oder besser gleich `git rm` – macht die Löschung Teil des nächsten Commits.

### `git rm`: Löschen und Vormerken in einem Schritt

Der saubere Weg führt über `git rm`. Der Befehl entfernt die Datei gleichzeitig aus dem Arbeitsverzeichnis *und* aus dem Index:

```bash
git rm beispiel.txt
```

```
rm 'beispiel.txt'
```

Ein anschließendes `git status` zeigt die Datei bereits als *vorgemerkt zum Löschen* (`staged: deleted`). Ein Commit schließt den Vorgang ab:

```bash
git commit -m "Entferne veraltete Datei beispiel.txt"
```

### Nur aus der Versionskontrolle entfernen, Datei behalten

Häufig soll eine Datei nicht mehr von Git verfolgt werden, aber weiterhin lokal existieren – etwa eine Konfigurationsdatei mit lokalen Einstellungen oder eine versehentlich committete `.env`-Datei. Dafür gibt es die Option `--cached`:

```bash
git rm --cached config.local.php
```

Dieser Befehl entfernt die Datei ausschließlich aus dem Index. Im Arbeitsverzeichnis bleibt sie unverändert erhalten, taucht danach aber als *nicht verfolgt* auf. In Kombination mit einem passenden Eintrag in `.gitignore` verschwindet sie danach dauerhaft aus zukünftigen Vorschlägen von `git status`.

> **Praxistipp:** Diese Kombination – `git rm --cached` gefolgt von einem `.gitignore`-Eintrag – ist der Standardweg, um versehentlich eingecheckte Zugangsdaten oder generierte Dateien nachträglich aus der Nachverfolgung zu entfernen. Die vollständige Entfernung aus der *Historie* erfordert dagegen weiterführende Werkzeuge, die in späteren Kapiteln behandelt werden.

### Bereits gelöschte Dateien nachträglich stagen

Wurde eine Datei bereits klassisch gelöscht, bevor du an `git rm` gedacht hast, musst du das Repository nicht zurücksetzen. `git add` merkt auch Löschungen korrekt vor:

```bash
git add beispiel.txt
```

Git erkennt, dass die Datei fehlt, und merkt diesen Zustand als Löschung vor – der Effekt ist identisch zu `git rm`.

### Verzeichnisse rekursiv entfernen

Soll ein ganzes Verzeichnis samt Inhalt entfernt werden, ist die Option `-r` erforderlich:

```bash
git rm -r temp/
```

Ohne diese Option verweigert Git die Operation, um versehentliches Löschen ganzer Verzeichnisbäume zu verhindern.

### Löschung erzwingen

Enthält eine Datei nicht committete Änderungen, verweigert `git rm` standardmäßig die Löschung, um Datenverlust zu vermeiden:

```
error: the following file has local modifications:
    beispiel.txt
```

Mit der Option `-f` (force) wird die Löschung dennoch durchgeführt:

```bash
git rm -f beispiel.txt
```

Diese Schutzmechanik ist bewusst restriktiv gestaltet – ein typisches Beispiel für Gits generelle Haltung, lieber einen expliziten zusätzlichen Schritt zu verlangen, als Arbeit unwiderruflich zu verwerfen.

### Übersicht der wichtigsten Varianten

| Befehl | Wirkung auf Arbeitsverzeichnis | Wirkung auf Index |
|---|---|---|
| `git rm datei` | Datei wird gelöscht | Löschung vorgemerkt |
| `git rm --cached datei` | Datei bleibt erhalten | Löschung vorgemerkt |
| `git rm -r verzeichnis/` | Verzeichnis wird gelöscht | Löschung vorgemerkt |
| `git rm -f datei` | Datei wird trotz Änderungen gelöscht | Löschung vorgemerkt |
| Manuelles Löschen + `git add` | Datei bereits gelöscht | Löschung nachträglich vorgemerkt |

### Ausblick auf PhpStorm

PhpStorm bildet diese Vorgänge grafisch nach: Ein Löschen einer Datei im *Project*-Werkzeugfenster fragt automatisch, ob die Löschung auch in Git vorgemerkt werden soll, und übernimmt intern denselben `git rm`-Mechanismus. Wie dieser Ablauf konkret aussieht und sich in die übrige IDE-Bedienung einfügt, zeigt der letzte Abschnitt dieses Kapitels, in dem der gesamte bisherige Workflow noch einmal vollständig innerhalb von PhpStorm nachvollzogen wird.

# Derselbe Workflow in PhpStorm

Die vorherigen Abschnitte dieses Kapitels haben den kompletten Weg von `git init` bis zum Entfernen einzelner Dateien ausschließlich über die Kommandozeile beschritten. Das war kein Zufall: Wer die Befehle einmal *bewusst* eingegeben hat, versteht später jede grafische Schaltfläche, die im Hintergrund exakt denselben Befehl auslöst. Dieser Abschnitt wiederholt nun den identischen Workflow – Repository anlegen, Zustand prüfen, Dateien vormerken, committen, Historie lesen, Diffs betrachten, umbenennen und entfernen – vollständig über die Oberfläche von PhpStorm.

Das Ziel ist nicht, die Kommandozeile zu ersetzen, sondern eine bewusste **Übersetzungstabelle** im Kopf zu verankern: „Wenn ich diesen Button klicke, passiert intern dieser Befehl.“

---

### Vom Übungsprojekt zum versionierten Verzeichnis

Öffne das Übungsprojekt aus den vorherigen Abschnitten in PhpStorm, sofern es noch nicht als Repository initialisiert wurde. Der Menüpfad dafür lautet:

> `VCS → Enable Version Control Integration…`

PhpStorm fragt anschließend nach dem gewünschten Versionskontrollsystem und bietet *Git* als Option an. Nach Bestätigung führt die IDE im Hintergrund exakt den Befehl aus, den du bereits kennst:

$$
\texttt{git init}
$$

Ein neues `.git`-Verzeichnis entsteht, unsichtbar für den Datei-Explorer, aber sichtbar im PhpStorm-Projektbaum, sofern versteckte Dateien angezeigt werden. Die Statusleiste am unteren Bildschirmrand zeigt ab sofort den aktuellen Branch-Namen an – ein erstes visuelles Signal, dass Versionskontrolle aktiv ist.

---

### Den Zustand prüfen: Local Changes statt `git status`

Anstelle von `git status` nutzt PhpStorm das Werkzeugfenster **Commit** (früher „Local Changes“ genannt), erreichbar über:

> `View → Tool Windows → Commit`

Hier erscheinen alle veränderten, neuen und gelöschten Dateien in einer strukturierten Liste, farblich unterschieden:

- **Grün** – neue, noch nicht verfolgte Dateien
- **Blau** – bereits verfolgte, aber veränderte Dateien
- **Rot** – gelöschte Dateien

Diese Darstellung liefert dieselbe Information wie `git status`, jedoch dauerhaft aktualisiert und ohne erneuten Befehlsaufruf. Ein Klick auf eine Datei öffnet sofort die Diff-Ansicht – ein Komfort, den die reine Kommandozeile nicht bietet.

---

### Dateien vormerken: Checkboxen statt `git add`

Im Commit-Fenster besitzt jede Datei eine Checkbox. Ist sie aktiviert, wird die Datei beim nächsten Commit einbezogen – funktional entspricht das exakt:

$$
\texttt{git add <datei>}
$$

Wichtig zu verstehen: Das reine *Anhaken* einer Datei löst in PhpStorm **noch nicht sofort** einen `git add`-Befehl aus. Stattdessen merkt sich die IDE die Auswahl und führt das eigentliche Staging erst beim Commit-Vorgang durch. Für Nutzer, die den exakten Zeitpunkt des Stagings kontrollieren möchten, lässt sich dieses Verhalten in den Einstellungen anpassen unter:

> `Settings → Version Control → Commit`

Wer gezielt nur Teile einer Datei vormerken möchte, öffnet über einen Rechtsklick den Diff-Viewer und aktiviert dort einzelne Änderungsblöcke – das grafische Äquivalent zu `git add -p`, das im nächsten Kapitel vertieft wird.

---

### Den ersten Commit erstellen

Mit ausgewählten Dateien öffnest du das Commit-Fenster über `Strg + K` (unter Windows 11 die gebräuchliche Tastenkombination in PhpStorm) oder über die Schaltfläche **Commit** in der Werkzeugleiste. Ein Textfeld erwartet die Commit-Nachricht – dieselbe Nachricht, die bei der Kommandozeile über

$$
\texttt{git commit -m "Nachricht"}
$$

übergeben würde. PhpStorm bietet zusätzlich:

- Eine **Kommentarvorlage**, sofern im Projekt konfiguriert
- Automatische **Rechtschreibprüfung**
- Optionale **Vor-Commit-Prüfungen** (z. B. Codeanalyse, TODO-Kommentare), die sich einzeln aktivieren oder deaktivieren lassen

Die Schaltfläche **Commit** entspricht einem einfachen Commit; **Commit and Push…** führt zusätzlich sofort einen Push aus – ein Vorgriff auf spätere Kapitel, der hier bewusst noch nicht verwendet werden sollte.

---

### Historie lesen: Das Git-Log-Fenster statt `git log`

Die textbasierte Ausgabe von `git log` findet ihre grafische Entsprechung im Werkzeugfenster **Git**, Reiter **Log**:

> `View → Tool Windows → Git`

Dort erscheint jeder Commit als Zeile in einem Graphen, ergänzt um Autor, Zeitstempel und vollständige Nachricht im Detailbereich. Ein Klick auf einen Commit zeigt sofort dessen Änderungen an – ohne zusätzlichen Befehl wie `git show`. Die Filterleiste oberhalb des Logs ermöglicht Suchen nach Autor, Branch oder Nachricht, was in der Kommandozeile erst mit Optionen wie `--author` oder `--grep` möglich wäre.

---

### Änderungen untersuchen: Der integrierte Diff-Viewer

Statt `git diff` in der Konsole zu lesen, öffnet ein Doppelklick auf eine geänderte Datei im Commit-Fenster den **Diff-Viewer** von PhpStorm. Er stellt alte und neue Version einer Datei Seite an Seite dar, farblich markiert, mit Navigationspfeilen zwischen den einzelnen Änderungsblöcken. Diese Darstellung ist inhaltlich identisch mit der textuellen Diff-Ausgabe, jedoch erheblich leichter lesbar – besonders bei umfangreichen Änderungen oder verschachtelten Codeblöcken.

---

### Dateien umbenennen und verschieben

Ein einfacher Rechtsklick im Projektbaum mit der Option **Refactor → Rename** bzw. **Move** genügt. PhpStorm erkennt, dass die Datei unter Versionskontrolle steht, und führt automatisch die passende Git-Operation aus – intern entspricht dies:

$$
\texttt{git mv <alt> <neu>}
$$

Der entscheidende Vorteil gegenüber einer manuellen Umbenennung im Windows-Explorer: PhpStorm passt zugleich alle Codeverweise auf die Datei an, etwa `require`- oder `use`-Anweisungen in PHP – eine Funktion, die reines Git nicht kennt.

---

### Dateien aus Git entfernen

Löschst du eine Datei über den Projektbaum (`Entf`-Taste) oder direkt im Datei-Explorer, erkennt PhpStorm die Löschung im Commit-Fenster als rote Zeile. Beim anschließenden Commit wird sie regulär aus der Versionsverwaltung entfernt – gleichbedeutend mit:

$$
\texttt{git rm <datei>}
$$

Möchtest du eine Datei zwar physisch behalten, aber aus der Nachverfolgung entnehmen, bietet der Rechtsklick im Commit-Fenster die Option **Rollback** oder **Ignore**, was Kapitel 7 vertieft.

---

### Gegenüberstellung: Befehl und Oberfläche

| Aufgabe | Kommandozeile | PhpStorm |
| --- | --- | --- |
| Repository anlegen | `git init` | `VCS → Enable Version Control Integration` |
| Zustand prüfen | `git status` | Werkzeugfenster *Commit* |
| Datei vormerken | `git add` | Checkbox im Commit-Fenster |
| Commit erstellen | `git commit -m "…"` | Schaltfläche *Commit* |
| Historie ansehen | `git log` | Werkzeugfenster *Git → Log* |
| Änderungen vergleichen | `git diff` | Integrierter Diff-Viewer |
| Datei umbenennen | `git mv` | *Refactor → Rename* |
| Datei entfernen | `git rm` | Löschen \+ Commit |

---

### Einordnung: Wann welches Werkzeug?

Die grafische Oberfläche punktet bei **Übersicht, Diff-Lesbarkeit und Refactoring-Integration** – besonders wertvoll bei umfangreichen PHP-Projekten mit vielen Abhängigkeiten zwischen Dateien. Die Kommandozeile bleibt unschlagbar bei **Automatisierung, Skripten, Fernzugriffen über SSH** und in Situationen, in denen kein grafisches Werkzeug zur Verfügung steht.

Ein erfahrener Git-Anwender wechselt bewusst zwischen beiden Welten, statt sich auf eine einzige Methode zu versteifen. 🧭 Genau dieses flexible Zusammenspiel bildet die Grundlage für alle folgenden Kapitel, in denen Branching, Merging und Teamarbeit sowohl über die Kommandozeile als auch über PhpStorm demonstriert werden.