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).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
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.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
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.
Git: Verteiltes Versionskontroll-System — jeder Entwickler hat die komplette Historie lokal, kann offline arbeiten und Änderungen mit anderen synchronisieren.
Ohne Git:
Mit Git:
.git/ ← Versteckter Ordner mit gesamter Historie
├── objects/ ← Alle Commits, Trees, Blobs
├── refs/ ← Branch-Pointer, Tags
└── HEAD ← Aktueller Commit
┌──────────────┐ git add ┌──────────────┐ git commit ┌──────────────┐
│ Working │ ───────────→ │ Staging │ ──────────────→ │ Repository │
│ Directory │ │ Area │ │ (Commits) │
│ (Dateien) │ │ (Snapshot) │ │ │
└──────────────┘ └──────────────┘ └──────────────┘
↓ ↑
└──── git checkout / git restore ────┘
3 Bereiche:
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).
# 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
# 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 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
# Ä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
# Branch in aktuellen mergen
git merge feature/login
# Rebase: Commits "umpacken" auf neue Basis
git rebase main
main ────────●────────●────── (Production-Releases)
\ \
develop ───●───●──●───●───●── (Integration)
\ \
feature/x ───●──● ●──●── (Feature-Entwicklung)
Branches: main, develop, feature/*, release/*, hotfix/*.
main ────●────●────●────●────●── (immer deploybar)
\ \ \
feature/x ─●──● ●──● ●──●── (kurze Feature-Branches)
Nur 2 Branch-Typen: main + feature/*. Heute bevorzugt in Web-Apps.
Alle pushen auf main, Feature-Flags trennen unfertiges Code. Sehr schnell, braucht Disziplin + CI.
Wenn zwei Branches dieselbe Datei in derselben Zeile geändert haben:
<<<<<<< HEAD
Meine Version
=======
Deren Version
>>>>>>> feature/login
Lösung:
git add datei.txt (markiert als gelöst).git commit (Merge fortsetzen).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!
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).
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!
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.
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.
6 Aufgaben zu Befehlen, Konzepten und Best-Practices.
Klausurfragen mit Lösungen (6)
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.
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.
Zuordnungen:
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
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.
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
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.
6 typische Klausurfragen zu Konzepten und Befehlen.
Klausurfragen mit Lösungen (6)
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.
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.
Lösungen pro Lücke:
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
Richtige Reihenfolge:
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
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.
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