Skip to main content

Die drei Bereiche in Git: Working Directory, Staging Area und Repository 📂

Wenn du zum ersten Mal mit Git arbeitest, fragst du dich vielleicht, warum das Speichern von Änderungen so „kompliziert" ist. Statt einfach auf „Speichern" zu klicken, musst du Dateien erst stagen und dann committen. Das wirkt anfangs umständlich – hat aber sehr gute Gründe, die dir mit der Zeit enorm helfen werden.

Die drei Bereiche im Überblick

Git organisiert dein Projekt in drei logische Bereiche, die jeweils eine bestimmte Rolle spielen:

flowchart LR
    WD["🗂️ Working Directory\nDein Arbeitsordner"]
    SA["📋 Staging Area\nVorbereitungsbereich"]
    REPO["📦 Repository\nDie Versionshistorie"]
    
    WD -->|git add| SA
    SA -->|git commit| REPO
    REPO -->|git checkout| WD

1. Working Directory – dein Arbeitsordner

Das Working Directory ist schlicht der Ordner auf deiner Festplatte, in dem du arbeitest. Hier liegen alle Dateien deines Projekts so, wie du sie gerade siehst und bearbeitest. Wenn du eine PHP-Datei öffnest, etwas änderst und speicherst (im klassischen Sinne mit Strg+S), dann ist diese Änderung nur im Working Directory – Git weiß davon noch nichts Besonderes.

💡 Merke: Das Working Directory ist der „echte" Zustand deiner Dateien, so wie du sie gerade auf dem Bildschirm siehst.

2. Staging Area – der Vorbereitungsbereich

Die Staging Area (manchmal auch Index genannt) ist ein Zwischenbereich, in dem du auswählst, welche Änderungen in den nächsten Commit kommen sollen. Du kannst sie dir wie einen Einkaufswagen vorstellen: Du legst Dinge hinein, aber erst an der Kasse (beim Commit) wird wirklich „abgerechnet".

Mit dem Befehl git add datei.php (oder in PhpStorm per Rechtsklick → Git → Add) verschiebst du eine Änderung vom Working Directory in die Staging Area. Die Datei ist damit vorgemerkt, aber noch nicht dauerhaft gespeichert.

💡 Merke: Die Staging Area gibt dir die Kontrolle darüber, was genau in einem Commit landet – nicht einfach „alles, was ich geändert habe".

3. Repository – die Versionshistorie

Das Repository (genauer: das lokale Repository) ist die eigentliche Git-Datenbank. Hier werden alle Commits gespeichert – also alle „Schnappschüsse" deines Projekts mit Autor, Zeitstempel und einer Nachricht. Sobald du git commit ausführst, wandern die Änderungen aus der Staging Area ins Repository und werden dauerhaft Teil der Versionsgeschichte.

Das Repository liegt im versteckten Ordner .git in deinem Projektverzeichnis. Du arbeitest normalerweise nicht direkt damit, sondern über Git-Befehle.

💡 Merke: Das Repository ist das „Gedächtnis" deines Projekts – hier kannst du jederzeit zu früheren Zuständen zurückkehren.

Warum nicht einfach „speichern"? 🤔

Die Dreiteilung mag auf den ersten Blick übertrieben wirken, aber sie löst mehrere echte Probleme:

  1. Gezielte Commits statt „alles auf einmal"

    Stell dir vor, du hast an drei verschiedenen Dingen gleichzeitig gearbeitet: einem Bugfix, einem neuen Feature und einer kleinen Textkorrektur. Ohne Staging Area müsstest du alles zusammen in einem Commit speichern – oder umständlich Dateien hin- und herkopieren. Mit der Staging Area kannst du gezielt auswählen: Erst den Bugfix committen, dann das Feature, dann die Textkorrektur. So bleibt deine Historie sauber und nachvollziehbar.

  2. Überprüfen vor dem Festschreiben

    Die Staging Area gibt dir einen Moment zum Innehalten. Du kannst mit git status oder in PhpStorm im Commit-Fenster genau sehen, welche Änderungen du gleich committen wirst. Das verhindert, dass versehentlich Debug-Code, temporäre Dateien oder unfertige Änderungen in die Versionshistorie gelangen.

  3. Teilweises Stagen möglich

    Du kannst sogar Teile einer Datei stagen (sogenanntes „partial staging" oder „hunks"). Wenn du in einer Datei zwei unabhängige Änderungen gemacht hast, kannst du nur eine davon in den nächsten Commit aufnehmen. Das ist mit einem einfachen „Speichern"-Konzept nicht möglich.

  4. Sicherheit und Flexibilität

    Solange Änderungen nur im Working Directory sind, kannst du sie jederzeit verwerfen. Solange sie nur in der Staging Area sind, kannst du sie wieder „unstagen". Erst wenn sie im Repository sind, sind sie dauerhaft (und selbst dann kannst du mit Git noch einiges korrigieren, aber das ist ein Thema für später).

Ein praktisches Beispiel

Angenommen, du arbeitest an einer Website und hast folgende Änderungen gemacht:

  • index.php – neues Kontaktformular hinzugefügt ✅
  • style.css – Farben angepasst ✅
  • config.php – versehentlich dein Datenbank-Passwort im Klartext eingetragen ❌

Ohne Staging Area würdest du alle drei Dateien auf einmal committen – inklusive des Passworts. 😬

Mit Staging Area machst du Folgendes:

git add index.php
git add style.css
# config.php wird NICHT hinzugefügt!
git commit -m "Kontaktformular und Farbänderungen hinzugefügt"

Du hast volle Kontrolle darüber, was ins Repository kommt. Das Passwort bleibt draußen, du kannst es in Ruhe korrigieren und später separat committen (oder die Datei in die .gitignore aufnehmen).

Zusammenfassung als Tabelle

Bereich Was ist das? Git-Befehl zum Wechsel
Working Directory Dein Projektordner mit allen aktuellen Dateien –
Staging Area Vorbereitungsbereich für den nächsten Commit git add
Repository Dauerhafte Versionshistorie aller Commits git commit

Fazit ✨

Die drei Bereiche in Git sind kein unnötiger Overhead, sondern ein durchdachtes System, das dir erlaubt:

  • saubere, thematisch getrennte Commits zu erstellen,
  • Änderungen vor dem Festschreiben zu überprüfen,
  • Fehler zu vermeiden, bevor sie in der Historie landen.

Sobald du dich daran gewöhnt hast, wirst du die Staging Area als eines der nützlichsten Features von Git schätzen lernen. In PhpStorm siehst du diese drei Bereiche übrigens sehr anschaulich im Commit-Fenster: Links die geänderten Dateien (Working Directory), in der Mitte die zum Commit vorgemerkten (Staging Area), und nach dem Commit landen sie in der Historie (Repository). 🚀

Back to top