edu@dorner-it
WerkzeugeEinsteiger18 min

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 --graph zeigt

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 hochladen

Branches 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 wechseln

Nach 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 feature

Git 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
>>>>>>> feature

Du musst die Datei manuell auflösen, dann:

git add <konflikt-datei>
git commit                    # schließt den Merge ab

Rebase — 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ückholen

Praxis-Ü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 --graph

Du 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 lg

Beispiel-Output:

* a3f1c2 (HEAD -> main) Merge branch 'feature/login'
|\
| * b81e9f (feature/login) Form-Validation
| * 4d3a7b Login-Komponente
* | f127aa Footer überarbeitet
|/
* 9c0e8d Initial commit

Weiterführendes


Wenn du den Graphen verstehst, verstehst du Git. 🌳