Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Wer ohne Git arbeitet, fährt Auto ohne Sicherheitsgurt. Git ist das mit Abstand wichtigste Werkzeug der Software-Entwicklung, egal welche Sprache, welches Framework, welches Team.
Die Idee in einem Satz
Git: Verteiltes Versionskontroll-System, jeder Entwickler hat die komplette Historie lokal, kann offline arbeiten und Änderungen mit anderen synchronisieren.
Warum Versionsverwaltung?
Ohne Git:
- "Welche Version hat eigentlich funktioniert?"
- "Wer hat das gestern abend kaputt gemacht?"
- "Lisa und ich haben beide dieselbe Datei geändert, was jetzt?"
- "Wie kommen wir zurück zur Version von vor 3 Wochen?"
Mit Git:
- Jede Änderung dokumentiert mit Autor, Zeitstempel, Begründung
- Mehrere Entwickler können parallel arbeiten
- Jede frühere Version ist wieder herstellbar
- Branches für Experimente, ohne den Haupt-Code zu gefährden
Die wichtigsten Git-Konzepte
Repository
.git/ ← Versteckter Ordner mit gesamter Historie
├── objects/ ← Alle Commits, Trees, Blobs
├── refs/ ← Branch-Pointer, Tags
└── HEAD ← Aktueller Commit
Working Directory, Staging Area, Repository
┌──────────────┐ git add ┌──────────────┐ git commit ┌──────────────┐
│ Working │ ───────────→ │ Staging │ ──────────────→ │ Repository │
│ Directory │ │ Area │ │ (Commits) │
│ (Dateien) │ │ (Snapshot) │ │ │
└──────────────┘ └──────────────┘ └──────────────┘
↓ ↑
└──── git checkout / git restore ────┘
3 Bereiche:
- Working Directory: Deine Dateien, mit denen du arbeitest.
- Staging Area (Index): Was im nächsten Commit landen soll.
- Repository (.git): Die persistente Historie.
Commit
Ein Commit ist ein Snapshot deines gesamten Codes zu einem bestimmten Zeitpunkt:
commit a3f5e8d
Author: Lisa <lisa@example.com>
Date: Tue May 25 14:23:00 2026
Fix: Login-Bug bei leerem Passwort
Jeder Commit hat einen eindeutigen Hash (SHA-1), und zeigt auf seinen/seine Eltern-Commit(s).
Die wichtigsten Git-Befehle
Setup
# Globale Konfiguration
git config --global user.name "Dein Name"
git config --global user.email "dein@email.com"
# Repository initialisieren
git init
# Bestehendes Repo klonen
git clone https://github.com/user/repo.git
Alltäglicher Workflow
# Status anschauen
git status
# Datei zum Commit vormerken
git add datei.txt
git add . # alle Änderungen
# Commit erstellen
git commit -m "Beschreibung der Änderung"
# Historie anschauen
git log
git log --oneline # kompakter
git log --graph # mit Branch-Visualisierung
Branches
# Branches anzeigen
git branch
# Neuen Branch erstellen + wechseln
git checkout -b feature/login
# oder (neuer Befehl):
git switch -c feature/login
# Branch wechseln
git checkout main
git switch main
# Branch löschen
git branch -d feature/login
Mit Remote (GitHub etc.) arbeiten
# Änderungen vom Remote holen
git fetch origin # nur holen, nicht mergen
git pull origin main # holen UND mergen
# Lokale Commits hochladen
git push origin main
# Neuen Branch hochladen
git push -u origin feature/login
Merging und Rebasing
# Branch in aktuellen mergen
git merge feature/login
# Rebase: Commits "umpacken" auf neue Basis
git rebase main
Branching-Strategien
Git Flow (klassisch, komplex)
main ────────●────────●────── (Production-Releases)
\ \
develop ───●───●──●───●───●── (Integration)
\ \
feature/x ───●──● ●──●── (Feature-Entwicklung)
Branches: main, develop, feature/*, release/*, hotfix/*.
GitHub Flow (einfacher)
main ────●────●────●────●────●── (immer deploybar)
\ \ \
feature/x ─●──● ●──● ●──●── (kurze Feature-Branches)
Nur 2 Branch-Typen: main + feature/*. Heute bevorzugt in Web-Apps.
Trunk-Based Development
Alle pushen auf main, Feature-Flags trennen unfertiges Code. Sehr schnell, braucht Disziplin + CI.
Konflikte lösen
Wenn zwei Branches dieselbe Datei in derselben Zeile geändert haben:
<<<<<<< HEAD
Meine Version
=======
Deren Version
>>>>>>> feature/login
Lösung:
- Datei manuell editieren, entscheiden, welche Version (oder Mix).
git add datei.txt(markiert als gelöst).git commit(Merge fortsetzen).
.gitignore
Datei, die festlegt, welche Dateien NICHT versioniert werden:
# Logs
*.log
# Build-Output
node_modules/
dist/
build/
# IDE-Dateien
.vscode/
.idea/
# Secrets
.env
*.pem
KRITISCH: Niemals Secrets (.env, API-Keys, Passwörter) committen, die bleiben für IMMER in der Historie, auch nach späterem Löschen!
Commit-Message-Konventionen
Gute Commit-Messages:
feat: add user registration form
fix: prevent crash on empty email
docs: update README with setup steps
refactor: extract Logger into separate class
test: add cases for negative numbers
chore: bump React to 19.0
Conventional Commits: <typ>: <kurze Beschreibung> (50 Zeichen max).
Klausur-Faustregeln
1. 3 Bereiche: Working Directory, Staging Area, Repository.
2. Wichtigste Befehle: add, commit, push, pull, checkout/switch, branch, merge, rebase.
3. Branch-Strategien: Git Flow (komplex), GitHub Flow (einfach), Trunk-Based.
4. Konflikte: Datei editieren, add, commit.
5. .gitignore: Was NICHT versioniert wird.
6. NIE Secrets committen!
Häufige Stolpersteine
1. Force-Push (git push --force) auf gemeinsame Branches. Damit überschreibst du die Historie für alle anderen Entwickler. Niemals auf main, nur eigene Branches.
2. .env committen. Klassischer Anfänger-Fehler. Wenn du es gemerkt hast: Datei löschen reicht NICHT, sie bleibt in der Historie. Du musst git filter-branch oder BFG Repo-Cleaner nutzen, plus alle Secrets rotieren!
3. Massive Commit-Messages oder leere wie "fix". Beides schlecht. Faustregel: ein Commit = eine logische Änderung, Message erklärt das WARUM, nicht das WAS.
4. git pull ohne git fetch zuerst. Pull kombiniert fetch + merge, wenn das Remote unerwartete Änderungen hat, wird automatisch gemergt. Sauberer: git fetch, dann git log origin/main schauen, dann manuell mergen/rebasen.
5. Branches lange leben lassen. Je länger ein Feature-Branch lebt, desto schwerer der Merge. Faustregel: max. 1 Woche, dann mergen oder verwerfen.
6. Merge-Konflikte ignorieren oder zufällig lösen. Konflikte verstehen ist Pflicht, sonst killt man Code anderer Entwickler. Bei Zweifel: mit dem anderen Entwickler reden.
Interaktiv verstehen
Git-Workflow durchspielen
Sieh, wie Dateien durch die 3 Git-Bereiche wandern (Working Directory → Staging → Repository) und experimentiere mit Branches.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Wenn ein Befehl gefragt wird, IMMER mitsagen WAS er tut UND in welchen Bereich er wirkt. git add = Working → Staging. git commit = Staging → Repository. git checkout = Repository → Working. Diese 3-Bereiche-Klarheit zeigt Verständnis.
Praxis-Übung
Git, Praxis-Übung
6 Aufgaben zu Befehlen, Konzepten und Best-Practices.
Klausurfragen mit Lösungen (6)
- F1.Welcher Git-Befehl markiert eine Datei für den nächsten Commit?
Antwort: git add
Erklärung: `git add` markiert Änderungen für den nächsten Commit, verschiebt sie aus dem Working Directory in die Staging Area. Erst `git commit` macht daraus dann einen tatsächlichen Commit im Repository. Das ist Git's 'Two-Stage Commit'-Prinzip.
- F2.Was sind die 3 Bereiche in Git?
Antwort: Working Directory, Staging Area, Repository
Erklärung: Git's 3 Bereiche: 1) Working Directory (deine aktuellen Dateien), 2) Staging Area / Index (was im nächsten Commit landet, durch `git add`), 3) Repository / .git (die persistente Historie, durch `git commit`). Wichtig: Local vs. Remote ist ein anderer Aspekt, beides hat seine eigenen 3 Bereiche.
- F3.Ordne die Git-Befehle ihrer Wirkung zu.
Zuordnungen:
- git add → Working Directory → Staging Area
- git commit → Staging Area → Repository
- git push → Lokales Repo → Remote-Repo
- git pull → Remote-Repo → Lokales Repo (fetch + merge)
Erklärung: Die 4 wichtigsten Git-Befehle und wo sie wirken. `git pull` ist Kombination aus `git fetch` (nur holen) + `git merge` (mit aktueller Branch zusammenführen). Klausur-Klassiker. Wer das auswendig kann, hat 80% der Git-Fragen schon.
Typ: Zuordnung
- F4.Was passiert bei einem Merge-Konflikt?
Antwort: Git markiert die Konfliktstellen in der Datei mit `<<<<<<<`, `=======`, `>>>>>>>` und der User muss manuell entscheiden
Erklärung: Bei Konflikten markiert Git die Stellen mit `<<<<<<< HEAD` (deine Version), `=======` (Trennung), `>>>>>>> branch-name` (andere Version). Der User muss manuell editieren, dann `git add` (markiert als gelöst) und `git commit` (führt Merge zu Ende). Git löscht NIE automatisch, das wäre Daten-Verlust.
- F5.Wenn man eine Datei mit Secrets aus dem Repo löscht und commited, sind die Secrets sicher entfernt.
Antwort: Falsch
Erklärung: FALSCH. Die Datei wird zwar im aktuellen Commit entfernt, aber bleibt in der HISTORIE, jeder, der das Repo klont, sieht die alten Commits inklusive Secrets. Echte Entfernung: `git filter-branch` oder besser `BFG Repo-Cleaner`. PLUS alle Secrets rotieren (Passwörter ändern, API-Keys neu generieren). Klassischer Anfänger-Fehler mit potentiell teuren Folgen.
Typ: Wahr/Falsch
- F6.Du hast einen Bug in deinem letzten Commit gefunden, aber noch nicht gepusht. Wie korrigierst du ihn am sinnvollsten?
Antwort: `git commit --amend` nach Fix (Commit überschreiben)
Erklärung: Wenn noch NICHT gepusht: `git commit --amend` ist sauber, fix + add, dann `git commit --amend`, und der bestehende Commit wird mit dem Fix überschrieben. WICHTIG: niemals `--amend` auf bereits GEPUSHTE Commits, das würde Historie verändern und alle anderen Entwickler verwirren. Faustregel: amend nur auf lokalen Commits.
Klausur-Quiz
Git, Klausur-Quiz
6 typische Klausurfragen zu Konzepten und Befehlen.
Klausurfragen mit Lösungen (6)
- F1.Wie wechselt man in Git zu einem anderen Branch?
Antwort: git checkout <branch> oder git switch <branch>
Erklärung: Branch-Wechsel: `git checkout <branch>` (alter Standard) oder `git switch <branch>` (neuer, klarerer Befehl seit Git 2.23). Beide funktionieren. Neuen Branch erstellen + wechseln: `git checkout -b <name>` oder `git switch -c <name>`. Klausur-Klassiker, beide Befehle kennen.
- F2.Was ist der Unterschied zwischen git fetch und git pull?
Antwort: git fetch holt vom Remote (ohne zu mergen), git pull holt UND merged
Erklärung: `git fetch` lädt nur Änderungen vom Remote ins lokale Repo (ohne aktuelle Branch zu verändern). `git pull` = `git fetch` + automatischer `git merge` der aktuellen Branch mit Remote-Branch. Empfehlung in Teams: lieber `fetch` + manuell `merge`/`rebase`, gibt mehr Kontrolle.
- F3.Git hat 3 Bereiche: {{1}} Directory (deine Dateien), {{2}} Area (was im nächsten Commit landet) und {{3}} (Historie). Mit git add verschiebt man Dateien aus dem ersten in den zweiten.
Lösungen pro Lücke:
- {{1}}: Working / working
- {{2}}: Staging / staging
- {{3}}: Repository / repository / Repo
Erklärung: Die 3 Git-Bereiche IMMER in dieser Reihenfolge können: Working Directory → Staging Area → Repository. Befehle dazu: `git add` (Working → Staging), `git commit` (Staging → Repo), `git checkout`/`restore` (zurück). Das ist Git-Foundation.
Typ: Lückentext
- F4.Bringe die Schritte eines typischen Git-Workflows in die richtige Reihenfolge.
Richtige Reihenfolge:
- git pull origin main (Updates holen)
- Datei login.tsx editieren
- git add login.tsx
- git commit -m 'Fix login bug'
- git push origin main
Erklärung: Standard-Workflow: 1) Pull (Updates holen, verhindert Konflikte später), 2) Datei editieren, 3) git add (Staging), 4) git commit (lokal), 5) git push (zum Remote). Best Practice: ALWAYS pull BEFORE work, sonst gibt es vermeidbare Konflikte.
Typ: Reihenfolge
- F5.Was bedeutet git push --force und wann sollte man es nutzen?
Antwort: Pusht und überschreibt die Remote-Historie, NIEMALS auf shared/main Branches
Erklärung: `git push --force` überschreibt die Remote-Historie mit der lokalen. SEHR GEFÄHRLICH: wenn andere Entwickler bereits die alte Historie gepullt haben, verlieren sie ihre Arbeit. Regel: NIEMALS force-push auf shared Branches (main, develop). Auf eigenen Feature-Branches OK (z.B. nach `rebase`). Sichere Alternative: `git push --force-with-lease` prüft ob Remote unverändert ist.
- F6.In einem .gitignore wird festgelegt, welche Dateien NICHT versioniert werden sollen.
Antwort: Wahr
Erklärung: RICHTIG. .gitignore enthält Pattern (z.B. `node_modules/`, `*.log`, `.env`), die Git ignoriert, diese Dateien werden NICHT versioniert. Typischer Inhalt: Build-Output, Dependencies, IDE-Configs, Logs, Secrets. WICHTIG: Wenn eine Datei BEREITS committed wurde, hilft .gitignore nicht mehr, die Datei muss erst per `git rm --cached` aus dem Index entfernt werden, bevor sie zu .gitignore funktioniert.
Typ: Wahr/Falsch
