Git Versionskontrolle

Definition: Git ist ein verteiltes Versionskontrollsystem (VCS), das 2005 von Linus Torvalds entwickelt wurde und heute das weltweit meistgenutzte System zur Quellcodeverwaltung ist. Git protokolliert lückenlos alle Änderungen an Dateien mit Zeitstempel, Autor und Beschreibung (Commits), ermöglicht parallele Entwicklungsstränge (Branches) und deren Zusammenführung (Merge). Plattformen wie GitHub, GitLab und Bitbucket bauen auf Git auf und ergänzen es um Collaboration-Features wie Pull Requests, Code Reviews und Issue Tracking. Git ist die Grundlage jeder CI/CD-Pipeline: jeder Commit kann automatisch Tests, Deployments und Quality Checks auslösen. Für Marketing-Teams ist Git relevant als Deployment-Trigger und als Audit-Log wann welche Änderung an Website, Tracking oder Konfiguration deployt wurde.

Erläuterung

Git verwaltet einen vollständigen Snapshot jedes Commit-Zustands, nicht nur Differenzen. Das erlaubt sofortiges Zurückspringen auf jeden früheren Zustand (git checkout, git revert) ohne Datenverlust. Distributed bedeutet: jeder Entwickler hat eine vollständige Kopie des Repositories – kein zentraler Single Point of Failure. Für Marketing-Teams ist die praktische Konsequenz: jede Landingpage-Änderung, jeder Tracking-Setup und jedes Deployment ist im Git-Log nachvollziehbar und bei Problemen rückgängig zu machen.

Git-Kernkonzepte

Repository (Repo): Projektverzeichnis mit vollständiger Versionshistorie; .git-Ordner enthält alle Metadaten; Remote Repository (GitHub/GitLab): gemeinsame Quelle für das Team; git clone: vollständige Kopie des Remote-Repos lokal; git pull: Änderungen vom Remote holen; git push: eigene Commits hochladen
Commits: Snapshot des Projektzustands zu einem Zeitpunkt; SHA-Hash als eindeutiger Identifier (z. B. a3f8c2d); Commit-Message: kurz (50 Zeichen Titel) + optionaler Body; git log zeigt vollständige Commit-Historie; git blame zeigt welcher Commit welche Zeile eingeführt hat; unveränderlich nach Erstellung
Branches: Parallele Entwicklungslinie; main/master = Produktions-Branch; feature/checkout-redesign für neues Feature; git checkout -b feature/new-landing erstellt und wechselt Branch; Änderungen auf Branch beeinflussen main nicht; nach Fertigstellung: Merge in main via Pull Request
Merge und Rebase: git merge: kombiniert zwei Branches, erzeugt Merge-Commit; git rebase: schreibt Commit-Historie linear um (sauberere Historie aber gefährlich auf geteilten Branches); Merge-Konflikte entstehen wenn beide Branches dieselbe Zeile geändert haben; Konflikte manuell lösen vor Merge-Abschluss

GitHub und GitLab als Plattformen

Pull Requests (PR) / Merge Requests (MR): Vorschlag: Branch in main mergen; Code Review durch Teammitglieder vor Merge; Kommentare, Suggestions, Approval-Workflow; automatische CI/CD-Checks als PR-Gates (Tests müssen grün sein); Basis für qualitätsgesicherten Deployment-Prozess
GitHub Actions: CI/CD-Plattform direkt in GitHub integriert; Workflow-Datei (.github/workflows/deploy.yml) definiert Schritte; Trigger: push to main, PR opened, cron schedule; automatisches Deployment auf Vercel/Netlify/AWS nach Merge; kostenlose Minuten für öffentliche Repos und private Repos bis Limit
Tags und Releases: git tag v1.2.3: markiert Commit als Release; semantische Versionierung (Major.Minor.Patch); GitHub Releases: Download-Artefakte + Changelog; Rollback auf vorherige Version: git checkout v1.2.2 + Deploy; unverzichtbar für nachvollziehbare Deployment-Historie
Issues und Milestones: Issue Tracking direkt im Repository; Labels für Kategorisierung (bug, enhancement, marketing-request); Milestones für Sprint-Planung; «closes #123» in Commit-Message schließt Issue automatisch; verbindet Code-Änderungen mit Business-Requirements

Branching-Strategien

GitFlow: Klassisch; main (Produktion), develop (Integration), feature/*, release/*, hotfix/*; klare Trennung; gut für Release-Zyklen mit Versionsnummern; Nachteil: viele parallele Branches, komplexe Merge-Prozesse; weniger geeignet für Continuous Deployment
Trunk-Based Development: Alle Entwickler arbeiten auf main (Trunk); kurzlebige Feature Branches (<1 Tag); häufige kleine Commits; Feature Flags für unfertigen Code; Voraussetzung für echtes CI/CD (mehrere Deployments täglich); Google und Facebook nutzen Trunk-Based Development
GitHub Flow: Vereinfachtes GitFlow; nur main + Feature Branches; PR → Review → Merge → sofortiges Deployment; einfacher als GitFlow; geeignet für Web-Projekte mit häufigen Deployments; Empfehlung für die meisten Marketing-Website-Projekte

Git im Marketing-Kontext

Deployment-Korrelation: git log --since="2024-01-15" --until="2024-01-15" zeigt was an einem Tag deployt wurde; bei Conversion-Einbruch: welcher Commit war kurz davor? git bisect: binäre Suche nach dem Commit der einen Bug eingeführt hat; unverzichtbar für Post-Incident-Analyse
Marketing-Konfigurationen versionieren: GTM-Container-Export, robots.txt, .htaccess, Tracking-Konfigurationen in Git; Änderungen nachvollziehbar und rückgängig machbar; Sicherheitsvorteil: kein Überschreiben ohne Commit-Spur; oft vernachlässigt aber sehr wertvoll bei Incidents
Rollback bei Marketing-Fehlern: Fehlerhafte Landingpage deployt? git revert HEAD erzeugt neuen Commit der vorherige Änderungen rückgängig macht; sicherer als git reset --hard (verändert Historie); Re-Deployment des Revert-Commits stellt Vorzustand in Minuten wieder her

Praxistipp: Fordern Sie als Marketing-Verantwortlicher Zugang zum Git-Repository (read-only reicht) und zum Deployment-Log. Wenn Conversion-Daten unerwartet einbrechen, ist die erste Diagnose-Frage: «Was wurde in den letzten 24 Stunden deployt?» – git log --oneline --since="yesterday" auf dem main-Branch beantwortet das in Sekunden. Vereinbaren Sie mit dem Entwicklungsteam, dass Commits die Marketing-relevante Bereiche betreffen (Checkout, Tracking, Analytics) eine standardisierte Prefix-Konvention nutzen (z. B. «[tracking]», «[checkout]») – das macht Deployment-Ursachen für Marketing-Incidents ohne technisches Wissen sofort auffindbar.