91 lines
3.1 KiB
Markdown
91 lines
3.1 KiB
Markdown
# 💡 Modul 01 – Grundkonzepte
|
||
|
||
Bevor du Git-Befehle tippst, lohnt es sich, das Konzept dahinter zu verstehen. Dieses Modul erklärt, wie Git Dateien verwaltet und was ein Commit wirklich ist.
|
||
|
||
---
|
||
|
||
## Das 3-Bereiche-Modell
|
||
|
||
Git arbeitet mit drei Bereichen. Jede Datei befindet sich immer in genau einem davon:
|
||
|
||
| Bereich | Deutsch | Was passiert hier? |
|
||
|---------|---------|-------------------|
|
||
| **Working Directory** | Arbeitsverzeichnis | Hier bearbeitest du deine Dateien normal |
|
||
| **Staging Area** | Bereitstellungsbereich | Hier sammelst du Änderungen für den nächsten Commit |
|
||
| **Repository** | Versionsdatenbank | Hier werden Commits dauerhaft gespeichert |
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
WD[Working Directory\n📝 Dateien bearbeiten] -->|git add| SA[Staging Area\n📋 Änderungen vorbereiten]
|
||
SA -->|git commit| REPO[Repository\n🗄️ Versionshistorie]
|
||
REPO -->|git checkout| WD
|
||
```
|
||
|
||
### Der Weg einer Änderung
|
||
|
||
1. Du änderst eine Datei im **Working Directory**
|
||
2. Mit `git add` legst du die Änderung in die **Staging Area** – du entscheidest, *was* in den nächsten Commit kommt
|
||
3. Mit `git commit` speicherst du alles aus der Staging Area als neuen **Commit** im Repository
|
||
|
||
> **Warum gibt es eine Staging Area?**
|
||
> Sie gibt dir die Kontrolle. Du kannst in 5 Dateien arbeiten, aber nur 2 davon in einem Commit zusammenfassen – weil sie thematisch zusammengehören.
|
||
|
||
---
|
||
|
||
## Was ist ein Commit?
|
||
|
||
Ein Commit ist ein **unveränderlicher Snapshot** deines Projekts zu einem bestimmten Zeitpunkt. Stell dir Commits wie **Speicherstände in einem Videospiel** vor:
|
||
|
||
- Du speicherst regelmäßig deinen Fortschritt
|
||
- Du kannst jederzeit zu einem früheren Speicherstand zurückkehren
|
||
- Jeder Speicherstand hat einen Zeitstempel und eine Beschreibung
|
||
|
||
Jeder Commit enthält:
|
||
- Einen eindeutigen **Hash** (z. B. `a3f9c12`) als ID
|
||
- Den **Autor** und **Zeitstempel**
|
||
- Eine **Commit-Nachricht** (von dir geschrieben)
|
||
- Den **Snapshot** aller Dateien in diesem Moment
|
||
- Eine Referenz auf den **vorherigen Commit** (den „Eltern-Commit")
|
||
|
||
---
|
||
|
||
## Lineare Commit-Historie
|
||
|
||
Eine typische Projekthistorie sieht so aus – jeder Commit zeigt auf seinen Vorgänger:
|
||
|
||
```mermaid
|
||
gitGraph
|
||
commit id: "Projekt angelegt"
|
||
commit id: "README hinzugefügt"
|
||
commit id: "Erste Inhalte"
|
||
commit id: "Tippfehler behoben"
|
||
commit id: "Version 1.0 fertig"
|
||
```
|
||
|
||
Der neueste Commit ist immer ganz rechts. Der Zeiger `HEAD` markiert, wo du dich gerade befindest.
|
||
|
||
---
|
||
|
||
## Wichtige Begriffe auf einen Blick
|
||
|
||
| Begriff | Bedeutung |
|
||
|---------|-----------|
|
||
| `HEAD` | Zeiger auf den aktuellen Commit / Branch |
|
||
| `main` | Standardname des Hauptbranches |
|
||
| Hash | Eindeutige ID eines Commits (z. B. `a3f9c12`) |
|
||
| Staging Area | Auch „Index" genannt |
|
||
| Tracked | Datei ist Git bekannt |
|
||
| Untracked | Datei ist Git noch nicht bekannt |
|
||
|
||
---
|
||
|
||
## ✅ Erfolgskriterien
|
||
|
||
- [ ] Du kannst die drei Bereiche von Git nennen und erklären
|
||
- [ ] Du weißt, was ein Commit ist und warum er unveränderlich ist
|
||
- [ ] Du verstehst, warum es eine Staging Area gibt
|
||
|
||
---
|
||
|
||
**Weiter geht's mit:** [02 – Erste Schritte](../02-erste-schritte/README.md)
|