Git-Basics: Versionierung verstehen
Die wichtigsten Git-Konzepte visuell erklärt — Commits, Branches, Merging und Rebasing. Mit interaktiven Diagrammen, die zeigen, was wirklich im Hintergrund passiert.
Zuletzt aktualisiert: 11. Mai 2026
Git fühlt sich am Anfang an wie Magie — bis man verstanden hat, was wirklich passiert. In diesem Kurs lernst du Git nicht über auswendiggelernte Kommandos, sondern über das mentale Modell darunter.
Lernziele
- Du verstehst, was ein Commit, eine Branch und ein Merge sind
- Du kannst die wichtigsten Befehle sicher einsetzen
- Du erkennst auf einen Blick, was ein
git log --graphzeigt
Was ist Git?
Git ist ein verteiltes Versionskontrollsystem. Es speichert nicht einzelne Dateien, sondern Snapshots des gesamten Projekts. Jeder Snapshot heißt Commit und hat eine eindeutige ID (Hash).
gitGraph commit id: "Initial commit" commit id: "Neue Startseite" commit id: "Bugfix Login" commit id: "Footer überarbeitet"
Jeder Commit zeigt auf seinen Vorgänger. So entsteht eine Kette.
Die drei Bereiche
Git unterscheidet drei Bereiche, in denen Dateien leben können:
flowchart LR
WD["Working Directory<br/><small>Deine Dateien</small>"]
SA["Staging Area<br/><small>Vorgemerkte Änderungen</small>"]
REP["Repository<br/><small>Commits / Historie</small>"]
WD -- "git add" --> SA
SA -- "git commit" --> REP
REP -. "git checkout" .-> WD| Bereich | Kommando |
|---|---|
| Working Directory → Staging | git add datei.txt |
| Staging → Repository | git commit -m "Nachricht" |
| Status prüfen | git status |
| Unterschiede sehen | git diff |
Die wichtigsten Kommandos
# Repository starten
git init # neues Repo im aktuellen Ordner
git clone <url> # bestehendes Repo herunterladen
# Status & Historie
git status # was ist geändert/staged?
git log --oneline --graph # Historie als Graph
# Änderungen aufnehmen
git add <datei> # einzelne Datei stagen
git add -p # interaktiv stagen (empfohlen!)
git commit -m "Nachricht" # Commit erstellen
# Mit Remote arbeiten
git pull # Remote-Änderungen holen
git push # eigene Commits hochladenBranches verstehen
Eine Branch ist nur ein Zeiger auf einen Commit. Mehr nicht. Das ist die wichtigste Erkenntnis über Git.
gitGraph commit id: "A" commit id: "B" commit id: "C" branch feature
Direkt nach git branch feature zeigen main und feature auf den
gleichen Commit. Erst durch neue Commits divergieren sie.
Eine neue Branch erstellen und wechseln
git switch -c feature/login # erstellt + wechselt
# alternativ:
git branch feature/login # nur erstellen
git switch feature/login # zu existierender Branch wechselnNach ein paar Commits
gitGraph commit id: "A" commit id: "B" commit id: "C" branch feature checkout feature commit id: "D" commit id: "E" commit id: "F"
main ist unverändert, feature ist drei Commits voraus.
Merging — zwei Branches zusammenführen
Zurück auf main wechseln und feature mergen:
git switch main
git merge featureGit hat zwei Strategien — abhängig davon, ob main selbst neue Commits
hat:
Fall 1: Fast-Forward Merge
main hat keine neuen Commits seit der Abzweigung — Git verschiebt nur
den Zeiger:
Vorher:
gitGraph commit id: "A" commit id: "B" commit id: "C" branch feature checkout feature commit id: "D" commit id: "E" commit id: "F"
Nachher (main wurde „vorgeschoben"):
gitGraph commit id: "A" commit id: "B" commit id: "C" commit id: "D" commit id: "E" commit id: "F"
Keine zusätzliche Commit-Nachricht, lineare Historie.
Fall 2: Three-Way Merge (mit Merge-Commit)
main hat inzwischen eigene Commits bekommen — Git erstellt einen
neuen Merge-Commit M, der zwei Eltern hat:
Vorher:
gitGraph commit id: "A" commit id: "B" commit id: "C" branch feature checkout feature commit id: "D" commit id: "E" commit id: "F" checkout main commit id: "G" commit id: "H"
Nachher (Merge-Commit M mit zwei Eltern):
gitGraph commit id: "A" commit id: "B" commit id: "C" branch feature checkout feature commit id: "D" commit id: "E" commit id: "F" checkout main commit id: "G" commit id: "H" merge feature id: "M"
Die Commit-Nachricht ist typischerweise: Merge branch 'feature' into main.
Konflikte
Wenn beide Branches die gleiche Stelle in der gleichen Datei geändert haben, kann Git nicht automatisch entscheiden:
<<<<<<< HEAD
Begrüßung auf main
=======
Begrüßung auf feature
>>>>>>> featureDu musst die Datei manuell auflösen, dann:
git add <konflikt-datei>
git commit # schließt den Merge abRebase — die Alternative zum Merge
Statt einen Merge-Commit zu erzeugen, kann Git deine Commits neu
auflegen, als wären sie auf dem aktuellen main-Stand entstanden:
Vorher:
gitGraph commit id: "A" commit id: "B" commit id: "C" branch feature checkout feature commit id: "D" commit id: "E" commit id: "F" checkout main commit id: "G" commit id: "H"
Nach git rebase main (auf feature):
gitGraph commit id: "A" commit id: "B" commit id: "C" commit id: "G" commit id: "H" branch feature checkout feature commit id: "D'" commit id: "E'" commit id: "F'"
Das Ergebnis ist eine lineare Historie. Die Commits D', E', F'
sind neue Commits mit gleichem Inhalt, aber neuer Eltern-Beziehung.
Goldene Regel: Rebase nie Commits, die bereits gepusht und mit anderen geteilt wurden. Das Umschreiben von gemeinsamer Historie verursacht große Verwirrung.
Merge oder Rebase — was wann?
| Situation | Empfehlung |
|---|---|
| Lokale Feature-Branch aktuell halten | git rebase main |
| Feature-Branch in main übernehmen | git merge (besser nachvollziehbar) |
| Geteilte Branch aufräumen | Finger weg vom Rebase |
| Kleiner Hotfix | Direkter Commit + Merge per Fast-Forward |
Häufige Befehle für den Alltag
# Letzten Commit ändern (nur lokal!)
git commit --amend
# Änderungen verwerfen
git restore <datei> # Working Directory zurücksetzen
git restore --staged <datei> # Staging zurücknehmen
# Branch löschen
git branch -d <name> # nur wenn gemerged
git branch -D <name> # mit Gewalt
# Letzten Commit rückgängig (Historie behalten)
git revert HEAD
# Stash – Änderungen zwischenparken
git stash # weglegen
git stash pop # zurückholenPraxis-Übung
Erstelle ein Spielprojekt und übe den klassischen Workflow:
mkdir spielwiese && cd spielwiese
git init
echo "# Mein Projekt" > README.md
git add README.md
git commit -m "Initial commit"
git switch -c feature/erste-aenderung
echo "Hallo Git" >> README.md
git commit -am "Begrüßung hinzugefügt"
git switch main
git merge feature/erste-aenderung
git log --oneline --graphDu solltest am Ende einen Graphen sehen, der genau wie die obigen Diagramme aussieht.
Visualisierung im Terminal
Mit dem richtigen Alias bekommst du jederzeit einen lesbaren Graphen:
git config --global alias.lg \
"log --oneline --graph --decorate --all"
git lgBeispiel-Output:
* a3f1c2 (HEAD -> main) Merge branch 'feature/login'
|\
| * b81e9f (feature/login) Form-Validation
| * 4d3a7b Login-Komponente
* | f127aa Footer überarbeitet
|/
* 9c0e8d Initial commitWeiterführendes
- Offizielles Git-Buch: https://git-scm.com/book/de/v2
- Visualisierung im Browser: https://learngitbranching.js.org/?locale=de
- Cheatsheet: https://education.github.com/git-cheat-sheet-education.pdf
Wenn du den Graphen verstehst, verstehst du Git. 🌳