Versionsverwaltungssysteme
Dieser Beitrag ist eine Begriffserklärung zu Versionsverwaltungssystemen – inklusive Prüfungsfragen, Kernkomponenten und Tags.
In a Nutshell
Ein Versionsverwaltungssystem speichert jede Änderung nachvollziehbar, ermöglicht paralleles Arbeiten mit Branches und stellt Nachvollziehbarkeit, Wiederherstellbarkeit und Kollaboration sicher.
Kompakte Fachbeschreibung
- DVCS (Git): komplette Historie lokal verfügbar
- Zentral (Subversion): Historie primär auf dem Server
Kernoperationen:
- Commit (atomare Änderung)
- Branch (parallele Entwicklung)
- Merge oder Rebase (Integration)
- Tag (Release markieren)
Team-Governance:
- Pull Requests + Reviews
- Branchschutz + Statuschecks (CI)
- signierte Commits
Traceability: Ticketreferenzen in Commits/PRs + Releases via Tags/Notes.
Prüfungsrelevante Stichpunkte
- Git vs. SVN erklären
- Commit enthält Metadaten + Hash
- Merge vs Rebase (Historie)
- Konfliktlösung (3‑Way Merge + Tests)
- PRs/Reviews für Qualität/Compliance
- Releases: Tags + Semver
- Security: Rechte, Signaturen, Audit Trails
Kernkomponenten
- Repository (lokal/remote)
- Working Tree + Staging Area
- Commits
- Branches
- Merge
- Rebase
- Tags
- Zugriffskontrolle
- Hooks/Automatisierung
- CI/CD-Integration
Praxisbeispiel (Workflow)
1) feature-branch erstellen
2) committen (klein, nachvollziehbar)
3) rebase auf main, Konflikte lösen
4) Pull Request + Review + CI grün
5) Merge
6) Release-Tag (z.B. v1.4.0) + Release Notes
Vorteile und Nachteile
Vorteile
- Nachvollziehbarkeit und Wiederherstellung
- parallele Entwicklung
- Qualität durch Reviews + CI
Nachteile
- Lernkurve (Konflikte/Rebase)
- Governance-Aufwand (Policies)
Typische Prüfungsfragen (mit Kurzantwort)
- Merge vs Rebase? Merge bewahrt verzweigte Historie, Rebase schreibt Branch linear um.
- Wozu Tags? Releases reproduzierbar markieren.
- Warum Pull Requests? Vier-Augen-Prinzip + Checks.
- Wie verknüpft man Code mit Anforderungen? Ticket-ID in Commits/PRs + Release Notes.