Staging & Commits verstehen | Programmieren Lernen

Die Staging Area ist eines der cleversten Features von Git - und gleichzeitig das, was Anfaenger am meisten verwirrt. Warum kann man nicht einfach direkt committen? In diesem Kapitel wirst du verstehen, warum die Staging Area so wertvoll ist und wie du sie fuer saubere Commits nutzt.

Warum gibt es die Staging Area?

Stell dir vor, du baust an einem Haus. Du hast heute die Kuechentueren eingebaut, das Bad gefliest und einen Riss in der Wand repariert. Das sind drei verschiedene Aufgaben. Wuerdest du alles in einem einzigen Eintrag ins Bautagebuch schreiben?

Nein! Du wuerdest drei separate Eintraege machen. Und genau dafuer ist die Staging Area da - sie erlaubt dir, deine Aenderungen in logische Einheiten aufzuteilen.

Ohne Staging Area

Alle Aenderungen → Ein grosser Commit
                   "Verschiedene Sachen gemacht"

Mit Staging Area

Aenderung 1 → Stage → Commit: "Kuechentueren eingebaut"
Aenderung 2 → Stage → Commit: "Bad gefliest"
Aenderung 3 → Stage → Commit: "Riss in der Wand repariert"

Der Git-Workflow im Detail

┌─────────────────┐    git add    ┌─────────────────┐   git commit   ┌─────────────────┐
│                 │  ──────────>  │                 │  ──────────>   │                 │
│  Working Dir    │              │  Staging Area   │               │  Repository     │
│  (Deine Arbeit) │  <──────────  │  (Index)        │               │  (Historie)     │
│                 │  git restore  │                 │               │                 │
│                 │   --staged    │                 │               │                 │
└─────────────────┘              └─────────────────┘               └─────────────────┘

Die Bereiche erklaert

Working Directory: Hier arbeitest du an deinen Dateien. Jede Aenderung, die du in deinem Editor machst, passiert hier.

Staging Area (Index): Der Vorbereitungsbereich. Hier sammelst du die Aenderungen, die in den naechsten Commit sollen. Du entscheidest, was hineinkommt.

Repository: Die permanente Historie. Sobald ein Commit erstellt ist, ist er Teil der Geschichte deines Projekts.

Selektives Staging in der Praxis

Szenario: Mehrere Aenderungen, mehrere Commits

Du hast an deinem Webprojekt gearbeitet und folgende Aenderungen gemacht:

Navigation in index.html hinzugefuegt
Tippfehler in about.html korrigiert
Neues CSS fuer die Navigation in style.css geschrieben

Statt alles in einen Commit zu packen, machst du zwei saubere Commits:

# Status anschauen
git status

On branch main
Changes not staged for commit:
        modified:   index.html
        modified:   about.html
        modified:   style.css

Commit 1: Navigation

# Nur die Dateien stagen, die zur Navigation gehoeren
git add index.html style.css
git commit -m "Hauptnavigation hinzugefuegt"

Commit 2: Tippfehler

git add about.html
git commit -m "Tippfehler auf der About-Seite korrigiert"

Teile einer Datei stagen

Manchmal hast du in einer einzelnen Datei Aenderungen gemacht, die zu verschiedenen Aufgaben gehoeren. Mit git add -p kannst du einzelne Aenderungsbloeecke (Hunks) auswaehlen:

git add -p index.html

@@ -5,6 +5,10 @@
     <title>Meine Webseite</title>
+    <meta name="description" content="Meine persoenliche Webseite">
 </head>
 <body>
Stage this hunk [y,n,q,a,d,s,e,?]?

Option	Bedeutung
`y`	Diesen Block stagen
`n`	Diesen Block ueberspringen
`q`	Beenden (nichts mehr stagen)
`a`	Diesen und alle folgenden Bloecke stagen
`s`	Block in kleinere Teile aufteilen

Anatomie eines guten Commits

Was gehoert in einen Commit?

Ein Commit sollte eine einzelne logische Aenderung enthalten. Hier sind Beispiele:

Gute Commits:

“Kontaktformular zur About-Seite hinzugefuegt”
“Footer-Styling fuer mobile Geraete angepasst”
“Defekten Link in der Navigation repariert”

Schlechte Commits:

“Verschiedene Aenderungen”
“Update”
“Work in progress”
“Alles auf einmal committed”

Die Faustregel

Wenn du deine Commit-Message nicht in einem kurzen Satz beschreiben kannst, ist der Commit wahrscheinlich zu gross. Teile ihn auf!

Commits untersuchen

Alle Commits anzeigen

git log --oneline

d4e5f6a Kontaktformular hinzugefuegt
a3f4b2c About-Seite erstellt
8e1d9f0 Navigation hinzugefuegt
5c2a1b3 Initiales Projekt

Einen bestimmten Commit anschauen

git show d4e5f6a

commit d4e5f6a...
Author: Dein Name <deine.email@beispiel.de>
Date:   Mon Mar 10 14:30:00 2026 +0100

    Kontaktformular hinzugefuegt

diff --git a/kontakt.html b/kontakt.html
new file mode 100644
--- /dev/null
+++ b/kontakt.html
@@ -0,0 +1,15 @@
+<!DOCTYPE html>
+<html>
+<head>
+    <title>Kontakt</title>
...

Welche Dateien hat ein Commit geaendert?

git show --stat d4e5f6a

 kontakt.html | 15 +++++++++++++++
 style.css    |  8 ++++++++
 2 files changed, 23 insertions(+)

Der Lebenszyklus einer Datei in Git

Eine Datei durchlaeuft in Git verschiedene Zustaende:

Untracked  →  Tracked (Unmodified)  →  Modified  →  Staged
    ↑                                                   |
    |              ← git rm ←          ← git restore    |
    |                                    --staged        |
    └────────────────────────────────────────────────────┘
                                                    git commit

Zustaende im Detail

Zustand	Beschreibung	Befehl zum Wechseln
Untracked	Git kennt die Datei nicht	`git add` → Tracked
Unmodified	Keine Aenderungen seit letztem Commit	Datei bearbeiten → Modified
Modified	Geaendert, aber nicht gestaged	`git add` → Staged
Staged	Bereit fuer den naechsten Commit	`git commit` → Unmodified

Fortgeschrittene Staging-Techniken

Alle geloeschten Dateien stagen

git add -u

Das staged alle Aenderungen an bereits getrackten Dateien (inklusive Loeschungen), aber keine neuen Dateien.

Staging rueckgaengig machen

# Eine bestimmte Datei unstagen
git restore --staged style.css

# Alle Dateien unstagen
git restore --staged .

Was ist gerade gestaged?

# Staged Aenderungen anzeigen
git diff --staged

# Welche Dateien sind gestaged?
git diff --staged --name-only

index.html
style.css

Praktisches Uebungsszenario

Lass uns einen kompletten Workflow mit mehreren Commits durchspielen:

# Starte ein neues Projekt
mkdir blog-projekt
cd blog-projekt
git init

# Erstelle die Grundstruktur
touch index.html style.css
# ... Fuege Inhalte hinzu ...

# Erster Commit: Grundstruktur
git add index.html style.css
git commit -m "Grundstruktur fuer Blog erstellt"

# Erstelle einen Blog-Post
touch blog-post-1.html
# ... Fuege Inhalt hinzu ...

# Aendere auch das CSS fuer Blog-Posts
# ... Aenderungen an style.css ...

# Zweiter Commit: Blog-Post und Styling
git add blog-post-1.html style.css
git commit -m "Ersten Blog-Post veroeffentlicht"

# Pruefe die Historie
git log --oneline

b2c3d4e Ersten Blog-Post veroeffentlicht
a1b2c3d Grundstruktur fuer Blog erstellt

Uebungen

Erstelle ein Projekt mit mindestens 5 Dateien und mache 5 separate Commits
Uebe selektives Staging: Aendere 3 Dateien, stage nur 2 und committe
Nutze git add -p, um Teile einer Datei zu stagen
Schaue dir mit git show an, was in einem bestimmten Commit passiert ist
Nutze git diff --staged, um gestaged Aenderungen vor dem Commit zu pruefen

Was kommt als Naechstes?

Im naechsten Kapitel lernst du, wie du gute Commit-Messages schreibst. Denn eine saubere Commit-Historie ist nur so gut wie die Beschreibungen, die du dazu schreibst.

Zusammenfassung

Die Staging Area ermoeglicht dir, Aenderungen in logische Commits aufzuteilen
Git hat drei Bereiche: Working Directory, Staging Area und Repository
Nutze selektives Staging, um saubere Commits zu erstellen
Ein guter Commit enthaelt eine einzelne logische Aenderung
Mit git add -p kannst du sogar Teile einer Datei stagen
git diff --staged zeigt dir, was im naechsten Commit landen wird
Dateien durchlaufen den Zyklus: Untracked → Modified → Staged → Committed

Pro-Tipp: Bevor du einen Commit erstellst, schau dir immer mit git diff --staged an, was genau du committen wirst. So vermeidest du, versehentlich Debug-Code oder unfertige Aenderungen mitzunehmen.