Git & Versionskontrolle — Änderungen nachvollziehbar halten

Versionskontrolle ist Pflicht in jedem Entwicklerteam. In der Prüfung geht es um Begriffe und Abläufe: Was ist ein Branch, was passiert beim Merge, wie löst man einen Konflikt?

Verteiltes Versionskontrollsystem

Git speichert nicht „den aktuellen Stand", sondern eine Kette von Commits. Jeder Commit ist ein Schnappschuss mit Verweis auf den Vorgänger, einer eindeutigen Kennung (Hash) und einer Nachricht. Weil jede Arbeitskopie die volle Historie enthält, ist Git verteilt: Man kann ohne Server committen und später synchronisieren.

Die drei Bereiche

Bereich	Bedeutung
Arbeitsverzeichnis	die Dateien auf der Festplatte
Staging-Bereich (Index)	was in den nächsten Commit soll (`git add`)
Repository	die committete Historie (`git commit`)

Typischer Ablauf: git status ansehen → git add datei → git commit -m "Nachricht" → git push zum Server.

Branching

Ein Branch ist nur ein Zeiger auf einen Commit — deshalb ist das Anlegen extrem billig. Üblich ist, für jede Aufgabe einen eigenen Branch anzulegen und über einen Pull Request zusammenzuführen.

git switch -c feature/login — Branch anlegen und wechseln
git merge main — Änderungen des Hauptzweigs in den eigenen holen
git rebase main — eigene Commits auf den aktuellen Stand umschreiben (saubere Historie)
git cherry-pick <hash> — einzelnen Commit gezielt übernehmen

Merge und Konflikte

Beim Zusammenführen zweier Branches vergleicht Git die Änderungen. Solange unterschiedliche Stellen betroffen sind, macht Git das automatisch (Fast-Forward oder Merge-Commit). Ändern beide Seiten dieselbe Stelle, entsteht ein Konflikt mit Markierungen:

<<<<<<< HEAD
Preis = brutto * 0.19
=======
Preis = brutto * 0.20
>>>>>>> feature/steuer

Auflösen heißt: den gewünschten Endstand herstellen, Marker entfernen, dann git add und git commit. Nicht die Marker-Markierungen stehen lassen — das ist der häufigste Anfängerfehler.

Faustregeln: Vor dem Branchwechsel immer git status prüfen, kleine und häufigere Commits statt Riesen-Commits, im Server-Workflow nicht auf dem Hauptzweig direkt arbeiten, und git log --oneline --graph lesen können.

Branching-Strategien

Modell	Kern
Feature-Branch	ein Branch je Aufgabe, Zusammenführung über PR
Git Flow	feste Branches für main, develop, feature, release, hotfix
Trunk-based	kurze Branches, häufige Integration in einen Hauptzweig — Basis für CI

Typische Prüfungsfallen

Clone und Fork verwechseln: Fork ist eine eigene Kopie auf dem Server, Clone die lokale Arbeitskopie.
Pull und Fetch: fetch holt nur, pull holt und führt zusammen.
Commit ≠ Push: Der Commit ist lokal, erst push geht zum Server.
Konfliktmarker vergessen — kompiliert eventuell, ist aber falsch.
Merge und Rebase gleichsetzen: Merge erhält die Verzweigung, Rebase schreibt um.

Weiter üben

Das Grundlagenwissen steht hier frei — geübt wird in der Lernplattform: über 1.300 Prüfungsfragen mit ausführlicher Erklärung zu jeder Antwort, Fortschritt im eigenen Konto.

Zur Lernplattform Weitere Themen