Version Control – Git, SVN & Branching-Strategien

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie alles über Version Control Systeme:

Definition: Was ist Version Control und warum ist es wichtig?
VCS-Typen: Zentral vs. verteilt (Git, SVN, Mercurial)
Git Commands: Die wichtigsten Befehle im Überblick
Branching-Strategien: GitFlow, GitHub Flow, Trunk-Based
Git-Hosting: GitHub, GitLab, Bitbucket im Vergleich
Best Practices: Professionelle Workflows und Tipps
FAQ: Häufige Fragen und Antworten

1. Was ist Version Control?

Definition

Version Control (auch Versionskontrolle oder Quellcodeverwaltung) ist ein System, das Änderungen an Dateien über die Zeit verfolgt. Es ermöglicht Entwicklern, zu jedem früheren Zeitpunkt den genauen Zustand des Codes wiederherzustellen, Änderungen nachzuvollziehen und parallel an verschiedenen Features zu arbeiten, ohne sich gegenseitig zu behindern.

Ohne Version Control müssten Entwickler manuell Kopien erstellen (z.B. "projekt_v1.zip", "projekt_v2_final.zip"), was schnell unübersichtlich wird und zu Datenverlust führt. Ein VCS löst diese Probleme durch automatische Versionsverwaltung, Merge-Funktionalität und Collaboration-Features.

Die drei Hauptfunktionen eines VCS: Historie (jeder Commit ist dokumentiert), Branching (parallele Entwicklung) und Collaboration (mehrere Entwickler arbeiten zusammen).

             Warum ist Version Control unverzichtbar?
            Historie: Jede Änderung ist dokumentiert – wer hat was wann geändert?
Rollback: Fehlerhafte Änderungen können rückgängig gemacht werden
Parallelarbeit: Mehrere Entwickler arbeiten gleichzeitig an verschiedenen Features
Code Review: Änderungen können vor dem Merge überprüft werden
Backup: Der Code ist auf einem Remote-Server gesichert
Branching: Experimentelle Features in isolierten Branches entwickeln

        

2. Die wichtigsten VCS im Vergleich

Es gibt verschiedene Types von Version Control Systemen – hier die drei wichtigsten:

01

Git

Distributed VCS · Marktführer

Das weltweit beliebteste VCS. Entwickelt von Linus Torvalds für die Linux-Kernel-Entwicklung.

Verteilt: Jeder Entwickler hat vollständige Historie
Schnell: Die meisten Operationen sind lokal
Flexibel: Branching und Merging sind einfach
Open Source: Kostenlos und gut dokumentiert

02

SVN (Subversion)

Zentralisiert · Enterprise-Standard

Ein zentralisiertes VCS, das in vielen Unternehmen noch im Einsatz ist. Einfach zu lernen, aber weniger flexibel als Git.

Zentralisiert: Ein zentraler Server speichert die Historie
Einfach: Lineare Versionshistorie, leicht verständlich
Atomare Commits: Commits sind immer vollständig
Langsamer: Netzwerk-Operationen nötig

03

Mercurial (Hg)

Distributed · Python-basiert

Ein verteiltes VCS, ähnlich wie Git, aber mit einfacherer Syntax. Wird von Facebook und Mozilla genutzt.

Verteilt: Wie Git, vollständige Historie lokal
Einfache Syntax: Kürzere Befehle als Git
Python-basiert: Gut erweiterbar
Weniger verbreitet: Kleinere Community

Git vs. SVN – Wann welches?

Git ist der moderne Standard und wird für die meisten Projekte empfohlen. Es ist schneller, flexibler und besser für verteilte Teams geeignet. SVN wird noch in einigen Unternehmen verwendet, besonders wenn eine zentrale Verwaltung bevorzugt wird oder große Binärdateien (z.B. Grafiken, Videos) versioniert werden müssen.

3. Die wichtigsten Git-Befehle

Hier sind die wichtigsten Git-Befehle, die Sie täglich verwenden werden:

Repository initialisieren

git init

Erstellt ein neues Git-Repository im aktuellen Verzeichnis. Einmalig am Projektstart.

Repository klonen

git clone <url>

Kopiert ein existierendes Repository von einem Remote-Server (z.B. GitHub) auf den lokalen Rechner.

Änderungen hinzufügen

git add <datei> git add .

Fügt geänderte Dateien zur Staging-Area hinzu. git add . fügt alle Änderungen hinzu.

Commit erstellen

git commit -m "Nachricht"

Speichert die Änderungen aus der Staging-Area mit einer beschreibenden Nachricht.

Änderungen pushen

git push origin <branch>

Lädt lokale Commits auf den Remote-Server hoch. origin ist der Standard-Remote-Name.

Änderungen pullen

git pull origin <branch>

Lädt Änderungen vom Remote-Server herunter und merged sie mit dem lokalen Branch.

Branch erstellen

git branch <name> git checkout -b <name>

Erstellt einen neuen Branch. checkout -b erstellt und wechselt direkt zum neuen Branch.

Branch mergen

git merge <branch>

Merged die Änderungen eines anderen Branches in den aktuellen Branch.

Historie anzeigen

git log git log --oneline

Zeigt die Commit-Historie an. --oneline zeigt eine kompakte Version.

Status anzeigen

git status

Zeigt den aktuellen Status: geänderte Dateien, Staging-Area, aktueller Branch.

Änderungen verwerfen

git checkout -- <datei> git reset HEAD <datei>

Verwirft lokale Änderungen oder entfernt Dateien aus der Staging-Area.

Tag erstellen

git tag -a v1.0 -m "Release"

Erstellt einen Tag für eine bestimmte Version (z.B. Releases).

             Typischer Git-Workflow
            Änderungen machen: Code bearbeiten
Status prüfen: git status
Änderungen hinzufügen: git add .
Commit erstellen: git commit -m "Beschreibung"
Pushen: git push origin main

        

4. Branching-Strategien

Branching-Strategien definieren, wie Teams mit Branches arbeiten. Hier die drei wichtigsten:

01

GitFlow

Strukturiert · Für Releases

Die klassische Branching-Strategie von Vincent Driessen. Ideal für Projekte mit festen Release-Zyklen und klaren Versionierungsregeln.

Branches: main develop feature/* release/* hotfix/*

02

GitHub Flow

Einfach · Für Continuous Deployment

Ein vereinfachter Workflow, der von GitHub empfohlen wird. Ideal für Web-Anwendungen mit häufigen Deployments und kleinen Teams.

Branches: main feature/*

03

Trunk-Based Development

Minimalistisch · Für erfahrene Teams

Alle Entwickler arbeiten direkt auf dem main-Branch. Feature-Flags und kurze-lived Branches werden für experimentelle Features verwendet.

Branches: main kurze-lived Branches

             Welche Strategie für welches Team?
            GitFlow: Für große Teams mit festen Release-Zyklen (z.B. Desktop-Software, Mobile Apps)
GitHub Flow: Für kleine bis mittlere Teams mit Continuous Deployment (z.B. Web-Apps, SaaS)
Trunk-Based: Für erfahrene Teams mit hoher Testabdeckung und Feature-Flags (z.B. Google, Facebook)

        

5. Git-Hosting-Plattformen

Git-Hosting-Plattformen bieten Remote-Repositories und Collaboration-Features. Hier die drei wichtigsten:

GitHub

Marktführer · Open Source Community

Größte Entwickler-Community
GitHub Actions (CI/CD)
GitHub Pages (Hosting)
Pull Requests & Code Review
Issues & Projects

Preise: Kostenlos für öffentliche Repos, $4/Monat für private Repos (Team)

GitLab

All-in-One · Self-Hosting

Integrierte CI/CD Pipeline
Self-Hosting möglich
Container Registry
Issue Tracking & Wiki
Merge Requests

Preise: Kostenlos (Community Edition), $29/Monat (Premium)

Bitbucket

Atlassian · Jira-Integration

Tiefe Jira-Integration
Bitbucket Pipelines (CI/CD)
Pull Requests
LFS (Large File Storage)
Code Insights

Preise: Kostenlos für bis zu 5 User, $3/User/Monat (Standard)

             Welche Plattform für welches Projekt?
            GitHub: Für Open-Source-Projekte und maximale Community-Reichweite
GitLab: Für Unternehmen mit Self-Hosting-Anforderungen und integrierter CI/CD
Bitbucket: Für Teams, die bereits Jira und andere Atlassian-Tools nutzen

        

6. Best Practices

Professionelle Workflows und Tipps für effektive Versionskontrolle:

Commit-Regeln

Atomic Commits: Ein Commit = eine logische Änderung
Klare Nachrichten: Imperativ, beschreibend (z.B. "Add user login")
Häufig committen: Lieber zu oft als zu selten
Keine Binärdateien: Nur Code und Konfiguration
.gitignore nutzen: Temporäre Dateien ausschließen

Branching-Regeln

Beschreibende Namen: feature/login, bugfix/header
Kurzlebig: Branches schnell mergen
Regelmäßig rebasen: Konflikte früh lösen
Keine direkten Commits auf main: Immer über Feature-Branches
Branches aufräumen: Gemergte Branches löschen

Code Review

Pull Requests nutzen: Änderungen vor Merge prüfen
Konstruktives Feedback: Respektvoll und spezifisch
Automatische Tests: CI/CD vor Merge ausführen
Mindestens 1 Reviewer: Vier-Augen-Prinzip
Dokumentation aktualisieren: README, CHANGELOG

Sicherheit

Keine Secrets committen: Passwörter, API-Keys ausschließen
SSH-Keys nutzen: Statt HTTPS für Authentication
Signed Commits: GPG-Signaturen für Authentizität
Branch Protection: Main-Branch schützen
Regelmäßige Audits: Historie auf Secrets prüfen

Git Commit Message Konventionen

Verwenden Sie Conventional Commits für konsistente Nachrichten:

feat: Neue Features
fix: Bugfixes
docs: Dokumentationsänderungen
style: Formatierung (keine Code-Änderung)
refactor: Code-Refactoring
test: Tests hinzufügen/ändern
chore: Wartungsaufgaben

7. FAQ – Häufige Fragen & Antworten

Häufige Fragen zu Version Control

Was ist der Unterschied zwischen Git und GitHub?

Git ist das Versionskontrollsystem selbst – es läuft lokal auf Ihrem Computer und verwaltet die Historie Ihrer Dateien. GitHub ist eine Hosting-Plattform für Git-Repositories – es bietet Remote-Storage, Collaboration-Features und Web-Interfaces. Sie können Git ohne GitHub nutzen (lokal), aber GitHub ohne Git nicht.

Was ist ein Merge Conflict und wie löse ich ihn?

Ein Merge Conflict tritt auf, wenn zwei Branches dieselbe Zeile Code unterschiedlich geändert haben. Git kann nicht automatisch entscheiden, welche Version korrekt ist.

Lösung:

Öffnen Sie die betroffene Datei in einem Editor
Suchen Sie nach Konflikt-Markern (<<<<<<<, =======, >>>>>>>)
Entscheiden Sie, welche Version Sie behalten möchten (oder kombinieren Sie beide)
Entfernen Sie die Konflikt-Marker
Speichern Sie die Datei und committen Sie die Lösung

Was ist der Unterschied zwischen git pull und git fetch?

git fetch: Lädt nur die Änderungen vom Remote-Server herunter, merged sie aber nicht mit Ihrem lokalen Branch. Sie können die Änderungen zuerst überprüfen.

git pull: Ist eine Kombination aus git fetch + git merge. Es lädt die Änderungen herunter und merged sie sofort mit Ihrem aktuellen Branch.

Empfehlung: Nutzen Sie git fetch gefolgt von git merge für mehr Kontrolle, oder git pull --rebase für eine saubere Historie.

Was ist rebasing und wann sollte ich es verwenden?

Rebasing verschiebt die Basis Ihres Branches auf einen anderen Commit. Es erstellt eine lineare Historie, indem es Ihre Commits "neu abspielt".

Wann nutzen?

Bevor Sie einen Feature-Branch in main mergen
Um eine saubere, lineare Historie zu erhalten
NIE auf öffentlichen Branches (z.B. main, develop) – nur auf lokalen Branches

Befehl: git rebase main (während Sie auf Ihrem Feature-Branch sind)

Was ist .gitignore und warum brauche ich das?

.gitignore ist eine Datei, die Git mitteilt, welche Dateien und Ordner nicht versioniert werden sollen. Typische Einträge:

node_modules/ (JavaScript-Abhängigkeiten)
.env (Umgebungsvariablen mit Secrets)
*.log (Log-Dateien)
dist/ oder build/ (Build-Artefakte)
.DS_Store (macOS-Systemdateien)

Wichtig: Secrets (Passwörter, API-Keys) niemals committen!

Wie mache ich eine Änderung rückgängig?

Es gibt verschiedene Möglichkeiten, je nachdem, was Sie rückgängig machen möchten:

Uncommitted Änderungen verwerfen: git checkout -- <datei>
Datei aus Staging entfernen: git reset HEAD <datei>
Letzten Commit rückgängig (Änderungen behalten): git reset --soft HEAD~1
Letzten Commit rückgängig (Änderungen verwerfen): git reset --hard HEAD~1
Commit in Historie rückgängig (sicher): git revert <commit-hash>

Vorsicht: git reset --hard und git revert auf öffentlichen Branches können Probleme verursachen!

Was sind Tags und wann nutze ich sie?

Tags sind permanente Marker für bestimmte Commits, typischerweise für Releases (z.B. v1.0, v2.1.3).

Unterschied zu Branches:

Branches: Bewegen sich mit neuen Commits weiter
Tags: Bleiben immer auf demselben Commit (permanent)

Typische Verwendung:

Release-Markierungen (v1.0.0, v2.0.0)
Wichtige Meilensteine
Stabile Versionen für Produktion

Befehl: git tag -a v1.0.0 -m "Release 1.0.0"

Wie schütze ich sensible Daten in Git?

Best Practices für Secrets:

.gitignore: Dateien mit Secrets ausschließen (.env, config.json)
Umgebungsvariablen: Secrets nicht im Code hardcoden
Secret Manager: AWS Secrets Manager, Azure Key Vault, HashiCorp Vault
Pre-Commit Hooks: Tools wie git-secrets oder pre-commit nutzen
History prüfen: Falls Secrets bereits committet wurden: git filter-branch oder BFG Repo-Cleaner nutzen

Wichtig: Sobald ein Secret in der Git-Historie ist, gilt es als kompromittiert – sofort rotieren (neu generieren)!

Zusammenfassung

             Die wichtigsten Punkte
            Version Control: Unverzichtbar für professionelle Softwareentwicklung
Git: Der moderne Standard – verteilt, schnell, flexibel
Wichtigste Commands: init, clone, add, commit, push, pull, branch, merge
Branching-Strategien: GitFlow (strukturiert), GitHub Flow (einfach), Trunk-Based (minimalistisch)
Hosting-Plattformen: GitHub (Community), GitLab (Self-Hosting), Bitbucket (Jira-Integration)
Best Practices: Atomic Commits, klare Nachrichten, Code Review, keine Secrets
Sicherheit: SSH-Keys, Branch Protection, .gitignore, Signed Commits

        

Nächste Schritte

Beginnen Sie mit den Grundlagen: Installieren Sie Git, erstellen Sie ein Repository und üben Sie die wichtigsten Commands. Nutzen Sie GitHub oder GitLab für Remote-Repositories und lernen Sie Branching-Strategien kennen. Mit der Zeit werden Sie effizienter und können komplexere Workflows implementieren.

Weiterführende Themen

Programmiersprachen

Übersicht über die wichtigsten Programmiersprachen und ihre Einsatzgebiete.

Zu Programmiersprachen

Algorithmen

Grundlegende Algorithmen und Datenstrukturen für effiziente Softwareentwicklung.

Zu Algorithmen

Software-Engineering

Prinzipien und Praktiken für professionelle Softwareentwicklung.

Zu Software-Engineering

Testing

Teststrategien, Unit Tests, Integration Tests und Test-Driven Development.

Zu Testing