🗂️Die drei Bereiche

Jede Datei existiert in Git bis zu dreimal: im Arbeitsverzeichnis (was du bearbeitest), im Index (auch „Staging-Area“ – der Entwurf des nächsten Commits, gespeichert in .git/index) und im Repository (der letzte Commit, auf den HEAD zeigt). Fast alle Befehle kopieren Dateien zwischen diesen drei Orten.

🔁Der Weg einer Änderung

  Arbeitsverzeichnis        Index (Staging)          Repository (HEAD)
 ┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐
 │  app.js  (v2)    │───▶│  app.js  (v2)    │───▶│  Commit mit v2   │
 └──────────────────┘    └──────────────────┘    └──────────────────┘
          │  git add               │  git commit            │
          │◀───────────────────────┤                        │
          │    git restore <datei> │◀───────────────────────┤
          │                        │ git restore --staged   │
          │◀────────────────────────────────────────────────┤
                 git switch / git reset --hard / git restore --source

Lebenszyklus einer Datei (wie in „git status“):

  unversioniert ──git add──▶ vorgemerkt ──git commit──▶ unverändert
  (Untracked)                (Staged)                  (Unmodified)
                                 ▲                          │
                                 │ git add          bearbeiten
                                 │                          ▼
                                 └────────────────── geändert
                                                    (Modified)
  git rm --cached: versioniert ──▶ unversioniert (Datei bleibt liegen)

🎛️Spielplatz

Ein kleines Repository ohne Remote. Ändere Dateien, merke sie vor, committe, setze zurück – die Karten zeigen live, welche Fassung wo liegt.

📝 Arbeitsverzeichnis

Dateien auf der Platte

README.md
```
# Projekt
```
app.js
```
console.log("v1");
```

📋 Index (Staging-Area)

.git/index – nächster Commit

README.md
```
# Projekt
```
app.js
```
console.log("v1");
```

🗄️ Repository (HEAD)

letzter Commit

README.md
```
# Projekt
```
app.js
```
console.log("v1");
```

📄 Dateien bearbeiten (Arbeitsverzeichnis)

README.md

app.js

Zurücksetzen auf HEAD~1:Branch:

alice@laptop: ~/projekt

💡 Klicke auf die Knöpfe oder tippe selbst. Jede Aktion zeigt den echten Git-Befehl.

🌳 Commits

⏪reset --soft, --mixed, --hard im Vergleich

Derselbe Ausgangszustand, drei Befehle. Orange umrandet ist, was sich gegenüber „vorher“ ändert.

Ziel:

vorher

main → Commit

Index: a.txt

Arbeitsverzeichnis: a.txt

v4 (nicht committet)

Ausgangslage: Branch main zeigt auf v3, im Arbeitsverzeichnis steht eine nicht committete Änderung.

reset --soft

main → Commit

Index: a.txt

Arbeitsverzeichnis: a.txt

v4 (nicht committet)

Nur der Branch-Zeiger springt zurück. Index behält v3 → die Differenz zu v2 ist vorgemerkt (ideal zum Zusammenfassen von Commits).

reset --mixed

main → Commit

Index: a.txt

Arbeitsverzeichnis: a.txt

v4 (nicht committet)

Zeiger und Index springen zurück, das Arbeitsverzeichnis bleibt. Nichts ist mehr vorgemerkt. Das ist der Standard ohne Option.

reset --hard

main → Commit

Index: a.txt

Arbeitsverzeichnis: a.txt

Alles springt zurück – auch die nicht committete Zeile „v4“ ist weg. Committete Stände rettet das Reflog, nicht committete nicht!

🧮Welcher Befehl ändert welchen Bereich?

Befehl	HEAD / Branch	Index	Arbeitsverzeichnis	Zweck
git add <datei>	–	← Arbeitsverzeichnis	–	Änderung vormerken
git commit	neuer Commit, Branch rückt vor	–	–	Index wird zum Snapshot
git restore <datei>	–	–	← Index	lokale Änderung verwerfen ⚠️
git restore --staged <datei>	–	← HEAD	–	Vormerkung aufheben
git reset --soft <commit>	Branch → <commit>	–	–	Commits „aufmachen“
git reset [--mixed] <commit>	Branch → <commit>	← <commit>	–	Standard von reset
git reset --hard <commit>	Branch → <commit>	← <commit>	← <commit>	alles verwerfen ⚠️
git switch <branch>	HEAD → anderer Branch	← Branch-Spitze*	← Branch-Spitze*	*lokale Änderungen reisen mit
git stash	–	← HEAD	← HEAD	Änderungen parken

✅ checkout, switch und restore

git checkout konnte früher beides: Branches wechseln und Dateien wiederherstellen. Seit Git 2.23 gibt es dafür die klareren Befehle git switch (Branches) und git restore (Dateien).git checkout -- datei entspricht git restore datei.

⚠️ Was Git nicht retten kann

Alles, was nur im Arbeitsverzeichnis stand, ist nach git restore oder git reset --hard weg – Git hat davon nie ein Objekt gespeichert. Vorgemerkte Stände liegen dagegen als Blob in .git/objects (auffindbar mit git fsck --lost-found).