Git ist ein hervorragendes verteiltes Versionsverwaltungssystem – aber kein Deployment-Werkzeug für produktive Systeme. Diese Unterscheidung ist nicht optional, sie ist essenziell für Sicherheit, Stabilität und Wartbarkeit.
Git wurde entwickelt, um Quellcode zu verwalten, nicht um Software sicher und reproduzierbar in Produktion auszuliefern. Moderne Deployment-Workflows trennen diese Verantwortlichkeiten bewusst: Entwickler erzeugen getestete, unveränderliche Artefakte (Container, Pakete, Archives), die dann über CI/CD-Pipelines, Artefakt-Repositorien und orchestrierte Releases verteilt werden. Git spielt in diesem Ablauf die Rolle des Quellcode-Speichers, nicht des Lieferkanals.
Ein zentrales Problem bei der direkten Nutzung von Git auf Produktivsystemen sind die Sicherheitsrisiken. Git-Repositories enthalten nicht nur den aktuellen Code, sondern die gesamte Versionshistorie. Diese Historie kann sensible Informationen enthalten – frühere Konfigurationen, gelöschte Passwörter, API-Schlüssel –, die sich selbst dann rekonstruieren lassen, wenn sie im aktuellen Stand entfernt wurden. Außerdem kann schon das bloße Vorhandensein des versteckten .git-Verzeichnisses auf einem Webserver dazu führen, dass Angreifer über HTTP-Zugriffe komplette Source-Trees auslesen. Studien zeigen, dass weltweit Millionen von Webservern mit offen zugänglichen Git-Metadaten betrieben werden, wodurch Quellcode und oft auch Zugangsdaten exponiert werden. Ein Versionskontrollsystem auf dem Produktionshost erweitert die Angriffsfläche unnötig und potenziert Risiken, die es bei sauber getrennten Deployment-Prozessen nicht gäbe.
Hinzu kommt, dass Git keinerlei Gewähr für die Konsistenz von Abhängigkeiten bietet. Ein git pull auf dem Server aktualisiert zwar den Code, aber nicht zwangsläufig die exakten Laufzeit-Dependencies oder Build-Artefakte, die lokal getestet wurden. Ohne zusätzliche Mechanismen entsteht eine Situation, in der die Umgebung auf dem Produktionsserver nicht deterministisch reproduziert werden kann – ein klassischer Fall von „it works on my machine“, der sich schwer debuggen lässt und Fehler in Produktion begünstigt.
Deployment ist mehr als nur Code synchronisieren. Es umfasst Build-Prozesse, Sicherheits- und Qualitätsprüfungen, Artefakt-Signaturen, Rollout-Strategien und gegebenenfalls Genehmigungs-Stufen. Diese Kontrollpunkte entfallen, sobald Entwickler per einfachem Git-Pull direkt auf dem Produktivsystem arbeiten. Die klare Trennung von Entwicklungs- und Betriebsprozessen gehört zu den etablierten Best Practices in der Software-Entwicklung; Git in Produktion zu nutzen, unterminiert genau diese Trennung.
Kurz: Git gehört nicht auf Produktivsysteme als Mechanismus zur Auslieferung von Software. Es eignet sich nicht als Deployment-Werkzeug, bietet keine deterministische Abhängigkeitsauflösung, erhöht die Angriffsfläche und setzt Produktionsinfrastruktur unnötigen Risiken aus. Der Code gehört in ein Versionsverwaltungssystem; das Deployment gehört in einen kontrollierten, geprüften Release-Prozess. Beides zu vermischen ist nicht nur unsauber, es ist gefährlich.