Git für Cloud-Administratoren: Best Practices für Versionskontrolle jenseits der Softwareentwicklung

Von Mirko Peters · 2026-08-13

Willkommen zurück zu unserem Podcast und dem begleitenden Blog! Wenn Sie Cloud-Administrator, Systemingenieur oder DevOps-Praktiker sind, der die Verwaltung von Servern per Fernzugriff von Grund auf gelernt hat…

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück zum Podcast und zu unserem begleitenden Blog! Wenn Sie als Cloud-Administrator, Systemingenieur oder DevOps-Experte noch gewohnt sind, Server per Remote-Zugriff zu verwalten und Konfigurationsdateien direkt zu bearbeiten, atmen Sie bitte kurz durch. Wir müssen über Ihre Verzeichnisstruktur sprechen. Sie kennen das Problem: den Ordner auf dem Desktop oder, schlimmer, auf einem freigegebenen Netzlaufwerk oder einer Produktions-Jump-Box, mit Unterordnern wie production_config_final_v2_FINAL_fixed, nginx.conf.bak.old und main_terraform_script_DO_NOT_TOUCH_john. Wir alle kennen diese Situation. Wir alle haben in der chaotischen Welt manueller Sicherungen und händischer Dateikopien gelebt.

In diesem Beitrag vertiefen wir die heutige Podcast-Folge, in der wir genauer betrachten, warum Versionskontrollsysteme wie Git längst nicht mehr nur für Softwareentwickler gedacht sind. Wenn Sie Infrastructure-as-Code (IaC) schreiben, Cloud-Umgebungen verwalten oder Bereitstellungen automatisieren, wird Git zu Ihrem neuen besten Freund. Wir zeigen Ihnen, wie Sie von digitaler Datenansammlung zu einer professionellen, nachvollziehbaren und kollaborativen Cloud-Administration übergehen.

Warum Cloud-Administratoren Versionskontrolle brauchen

Jahrzehntelang konnten Softwareentwickler Git nutzen, während IT-Administratoren und Systemadministratoren auf manuelle Sicherungen, rsync-Skripte und ihr Gedächtnis angewiesen waren, um Änderungen nachzuverfolgen. Die Cloud hat diese Situation grundlegend verändert. Heute wird Ihre Infrastruktur in Code definiert. Ob Sie Terraform, Ansible, AWS CloudFormation, Kubernetes-Manifeste oder Pulumi einsetzen: Ihre Cloud-Umgebung ist eine direkte Abbildung von Textdateien.

Wenn Infrastruktur Code ist, ist es ein Rezept für Probleme, sie wie herkömmliche Daten zu verwalten. Hier sehen Sie, warum Cloud-Administratoren dringend Versionskontrolle benötigen:

• Der Prüfpfad: Wenn eine Produktionsdatenbank um 3:00 Uhr nachts ausfällt, möchte die Führungsebene wissen, was sich geändert hat. Mit Git genügt ein einziger Befehl, um zu sehen, wer wann und warum eine Sicherheitsgruppenregel geändert hat.
• Das Sicherheitsnetz: Haben Sie schon einmal eine nächtliche Konfigurationsänderung vorgenommen, die einen Load Balancer lahmgelegt hat, und erst danach gemerkt, dass Sie die ursprüngliche Einstellung vergessen hatten? Versionskontrolle bietet Ihnen eine sofort verfügbare Zeitmaschine, mit der Sie auf einen bekannten, stabilen Zustand zurückkehren können.
• Zusammenarbeit ohne Chaos: Zwei Ingenieure können dieselbe Konfigurationsdatei in einem freigegebenen Ordner nicht gleichzeitig bearbeiten, ohne dass einer die Arbeit des anderen überschreibt. Git löst dieses Problem grundlegend, indem es Beiträge sicher zusammenführt.
• CI/CD-Integration: Moderne Cloud-Workflows basieren auf Automatisierungspipelines. Git fungiert als zentrale Quelle der Wahrheit, die automatisierte Tests, Sicherheitsprüfungen und Bereitstellungspipelines auslöst, sobald eine Änderung genehmigt wurde.

Git-Kernkonzepte für Infrastruktur-Teams verständlich erklärt

Wenn Sie neu bei Git sind, kann die Terminologie für Systemadministratoren, die an klassische Dateisysteme gewöhnt sind, einschüchternd wirken. Wir übersetzen die Kernkonzepte in Begriffe, die für die Cloud-Verwaltung greifbar sind.

Repositories

Stellen Sie sich ein Git-Repository, kurz „Repo“, als einen Projektordner mit erweiterten Funktionen vor. Für einen Cloud-Administrator kann das ein einziges Repository sein, das alle Terraform-Konfigurationen für eine bestimmte Cloud-Umgebung enthält, oder ein zentrales Repo für sämtliche Kubernetes-Cluster-Manifeste. Das Repository verfolgt jede einzelne Datei und jeden Ordner darin und führt eine vollständige Historie aller jemals vorgenommenen Änderungen.

Commits

Ein Commit ist ein gespeicherter Snapshot Ihres Infrastrukturcodes zu einem bestimmten Zeitpunkt. Anders als beim einfachen Speichern einer Datei erfordert ein Commit eine bewusste Entscheidung. Sie stellen Ihre Änderungen bereit, etwa eine Firewall-Regel anpassen und einen neuen S3-Bucket hinzufügen, und committen sie anschließend mit einer aussagekräftigen Nachricht wie „Strikte CORS-Richtlinie für öffentlichen S3-Bucket hinzufügen.“ Dieser Snapshot ist dauerhaft, referenzierbar und eindeutig gehasht.

Branches

Branches sind die ultimative Lösung für das Problem mit Ordnernamen wie _v2_FINAL. Anstatt Ihre gesamte Verzeichnisstruktur zu duplizieren, um eine neue Netzwerktopologie zu testen, erstellen Sie einen "Branch". Ein Branch ist ein isolierter Arbeitsbereich. Sie können experimentieren, Dinge kaputt machen, neue Konfigurationen testen und in einer Staging-Umgebung bereitstellen, ohne den stabilen Produktivcode im Hauptbranch anzutasten.

Infrastructure-as-Code mit Commits und Verlauf verwalten

Gute Commits zu schreiben ist eine Kunst, für Cloud-Administratoren aber auch eine Compliance-Anforderung. Wenn Sie Cloud-Ressourcen verwalten, wird Ihr Commit-Verlauf zu Ihrem operativen Logbuch. Schauen wir uns an, wie Sie die Arbeit mit Git bei der Verwaltung von IaC strukturieren.

Stellen Sie sich vor, Sie stellen mit Terraform ein neues Virtual Private Cloud (VPC) bereit. Sie schreiben Ihre Datei vpc.tf, definieren Ihre Subnetze und konfigurieren Ihre Routing-Tabellen. Anstatt terraform apply blind auszuführen, sollte Ihr Workflow so aussehen:

1. Nehmen Sie Änderungen an den Konfigurationsdateien der Infrastruktur vor.
2. Führen Sie lokale Validierungswerkzeuge aus (etwa terraform validate oder Syntaxprüfungen).
3. Fügen Sie die gewünschten Dateien mit git add zur Staging-Area hinzu.
4. Erstellen Sie einen aussagekräftigen Commit mit git commit -m "Provision staging VPC and associated routing tables".
5. Pushen Sie Ihre Änderungen auf einen Remote-Server wie GitHub, GitLab oder Bitbucket.

Wenn Sie diesem Workflow folgen, erzählt Ihr Commit-Verlauf chronologisch die Entwicklung Ihrer Infrastruktur. Findet in sechs Monaten ein Audit statt, können Compliance-Beauftragte jede Infrastrukturänderung auf einen bestimmten Commit-Hash und Autor zurückverfolgen.

Branching-Strategien für sichere Cloud-Bereitstellungen

Einer der beunruhigendsten Momente in der Cloud-Administration ist es, ein Update direkt in einer Produktivumgebung einzuspielen. Traditionelle Sysadmin-Workflows fördern oft eine „Beten und bereitstellen“-Mentalität. Git-Branching-Strategien beseitigen diese Angst vollständig, indem sie strukturierte Isolation einführen.

Für Cloud-Administratoren funktioniert ein vereinfachter Git-Workflow – oft als GitHub Flow oder als modifiziertes Trunk-based-Development-Modell bezeichnet – besonders gut:

Der Main-Branch

Der Branch main (manchmal auch master) stellt die maßgebliche Quelle für Ihre Produktivinfrastruktur dar. Der Code in diesem Branch sollte exakt widerspiegeln, was aktuell in Ihrer Produktivumgebung läuft. Direkte Änderungen am Branch main sollten strikt untersagt sein.

Feature- und Aufgaben-Branches

Wenn Sie eine Änderung vornehmen müssen – etwa eine neue Datenbankinstanz hinzufügen, IAM-Rollen anpassen oder Node-Pools skalieren –, erstellen Sie einen eigenen Branch ausgehend von main. Sie könnten ihn aussagekräftig benennen, zum Beispiel feature/add-redis-cache oder fix/iam-policy-least-privilege.

Sie nehmen alle Änderungen vor, testen sie gründlich in einer Nicht-Produktiv-Sandbox und committen Ihre Änderungen in diesen Branch. Da Sie von main isoliert arbeiten, können Sie frei experimentieren, ohne einen Produktionsausfall zu riskieren.

Merging, Pull Requests und Teamzusammenarbeit

Sobald Sie Ihre Infrastrukturänderungen im Feature-Branch getestet haben und überzeugt sind, dass sie produktionsreif sind, stellt sich die Frage, wie sie in die Produktivumgebung gelangen. Hier kommen Merges und Pull Requests (PRs) ins Spiel.

Ein Pull Request (bei GitLab Merge Request) ist ein formeller Vorschlag, die Änderungen aus Ihrem Feature-Branch in den Produktions-Branch main zu übernehmen. Aus Sicht von Governance und Qualitätssicherung ist dies für Cloud-Administratoren der entscheidende Schritt.

Peer-Review

Bevor eine Infrastrukturänderung in die Produktivumgebung übernommen wird, kann ein Kollege Ihren Pull Request prüfen. Er kann die exakten Zeile-für-Zeile-Unterschiede Ihrer Terraform- oder Ansible-Skripte durchgehen. Haben Sie versehentlich eine offene Ingress-Regel hinterlassen, die Datenverkehr von 0.0.0.0/0 zulässt? Ihr Kollege kann das abfangen, bevor es jemals die API des Cloud-Anbieters erreicht.

Automatisierte Validierung über CI/CD

Wenn Sie einen Pull Request öffnen, können Sie Ihre Git-Hosting-Plattform so konfigurieren, dass automatisch Validierungspipelines gestartet werden. Beispielsweise kann Ihr CI/CD-System automatisch terraform plan ausführen und die Ausgabe direkt als Kommentar im Pull Request veröffentlichen. Das Team sieht genau, welche Ressourcen hinzugefügt, geändert oder gelöscht werden, bevor auch nur eine Zeile Code freigegeben wird.

Sobald das Peer Review abgeschlossen und die automatisierten Tests erfolgreich sind, klicken Sie auf die Schaltfläche "Merge". Ihre Änderungen sind damit sicher in main übernommen und bereit für die Bereitstellung.

Bewährte Methoden für produktionsreife Konfigurationen

Der Wechsel zu Git für die Cloud-Administration erfordert ein Umdenken. Damit Sie den größtmöglichen Nutzen aus Ihrem Versionsverwaltungssystem ziehen, sollten Sie die folgenden branchenüblichen Best Practices beachten:

1. Geheimnisse niemals committen

Das ist die goldene Regel der Git-Verwaltung. API-Schlüssel, Datenbankkennwörter, private SSH-Schlüssel und Zugangsdaten von Cloud-Anbietern (etwa geheime AWS-Zugriffsschlüssel) sollten niemals fest in Ihre Konfigurationsdateien geschrieben und in ein Repository committet werden. Wenn Sie ein Geheimnis in ein öffentliches Repository pushen – oder auch in ein internes, das kompromittiert wird –, können Angreifer es innerhalb weniger Minuten auslesen.

Verwenden Sie stattdessen Umgebungsvariablen und Dienste für die Geheimnisverwaltung (etwa AWS Secrets Manager, HashiCorp Vault oder Azure Key Vault). Konfigurieren Sie außerdem eine robuste .gitignore-Datei, damit lokale Statusdateien, Protokolldateien und Caches für Anmeldeinformationen ignoriert werden.

2. Aussagekräftige Commit-Nachrichten schreiben

Vermeiden Sie nachlässige Commit-Nachrichten wie fix stuff, update oder wip. Wenn Sie Monate später die Commit-Historie durchsuchen und herausfinden wollen, warum eine Autoscaling-Richtlinie geändert wurde, bewahrt Sie eine Nachricht wie Adjust CPU threshold scaling policy from 80% to 75% for peak traffic handling vor unnötigem Frust.

3. Infrastrukturdokumentation wie Code behandeln

Ihr Repository sollte nicht nur Bereitstellungsskripte enthalten. Legen Sie eine klare README.md-Datei in Ihrem Repository an, die die Architektur, die Voraussetzungen, die Bereitstellungsanleitung und die Kontaktdaten des für die Umgebung zuständigen Teams beschreibt.

4. Den Hauptzweig schützen

Konfigurieren Sie Branch-Schutzregeln in Ihrer Git-Plattform. Stellen Sie sicher, dass der Branch main mindestens ein Peer Review, erfolgreich bestandene automatisierte Prüfungen und keine Force Pushes erfordert. So werden versehentliche Überschreibungen verhindert und Governance-Richtlinien programmatisch durchgesetzt.

Fazit: Ihren Workflow für die Cloud-Administration auf die nächste Stufe heben

Wer sich von chaotischen Ordnerbenennungen, manuellen Konfigurationssicherungen und Deployments nach Gutsherrenart verabschiedet, macht einen der wirkungsvollsten beruflichen Schritte, die ein Cloud-Administrator gehen kann. Mit Git bringen Sie die Disziplin professioneller Softwareentwicklung in den Bereich Infrastruktur und Betrieb.

Versionsverwaltung ermöglicht es Ihnen, sicher zu experimentieren, reibungslos mit Ihrem Team zusammenzuarbeiten, Änderungen mühelos nachzuvollziehen und Fehler mit Zuversicht zurückzurollen. Aus Cloud-Administration wird so eine proaktive, planvoll gestaltete Disziplin statt eines reaktiven, stressigen Feuerlöschens.

Falls Sie es noch nicht getan haben: Richten Sie noch heute ein Testrepository ein, übertragen Sie ein kleines Konfigurationsskript hinein, legen Sie einen Branch an und erleben Sie die Sicherheit, die professionelle Versionsverwaltung mit sich bringt. Vielen Dank, dass Sie den Podcast eingeschaltet und mitgelesen haben. Abonnieren Sie gerne weitere Deep Dives zur Cloud-Infrastruktur. Bis zum nächsten Mal: Halten Sie Ihre Commits sauber und Ihre Pipelines grün!