Git-Deployment: Ihre Website automatisch mit Versionskontrolle deployen
Dateien manuell per FTP hochzuladen ist eine Arbeitsweise aus einer anderen Zeit. Es ist langsam, fehleranfällig und bietet keine Versionskontrolle. Git-Deployment modernisiert diesen Prozess: Sie pushen Ihren Code und Änderungen gehen automatisch live. In diesem ausführlichen Ratgeber erkläre ich, wie Sie Git-Deployment einrichten und optimal nutzen.
Warum von FTP auf Git-Deployment umsteigen?
Der traditionelle Workflow vieler Entwickler und Website-Betreiber ist einfach, aber problematisch. Sie bearbeiten Dateien lokal, öffnen einen FTP-Client, navigieren zum richtigen Ordner auf dem Server, laden die geänderten Dateien hoch und hoffen, dass alles funktioniert. Dieser Workflow hat grundlegende Probleme.
Es passiert leicht, dass Sie Dateien vergessen. Sie ändern fünf Dateien, laden vier davon hoch und fragen sich, warum die Seite nicht funktioniert. Ebenso leicht laden Sie die falsche Version hoch. Sie testen lokal, vergessen zu speichern, laden eine alte Version hoch und sehen die Änderungen nicht. Es gibt keine Historie darüber, was Sie wann geändert haben. Wenn etwas kaputtgeht, können Sie nicht einfach zu einer funktionierenden Version zurückkehren.
Git-Deployment löst all diese Probleme. Git erfasst, welche Dateien geändert wurden, Sie übersehen also nichts. Jede Änderung ist ein Commit mit einer Beschreibung, sodass Sie genau wissen, was Sie wann getan haben. Die vollständige Historie steht zur Verfügung, um bei Bedarf dorthin zurückzukehren. Und der Deployment-Prozess ist konsistent und wiederholbar.
Welche unterschiedlichen Ansätze für Git-Deployment gibt es?
Git Push zu einem Server-Remote
Die direkteste Methode ist die Konfiguration eines Git-Remotes auf Ihrem Produktionsserver. Sie pushen zu diesem Remote und ein Hook sorgt dafür, dass die Änderungen in Ihrem Website-Verzeichnis übernommen werden. Das erfordert SSH-Zugriff auf Ihren Server und etwas Konfiguration, ist danach aber einfach zu benutzen.
CI/CD-Pipelines
Pipelines für Continuous Integration und Continuous Deployment bieten mehr Kontrolle und Flexibilität. Plattformen wie GitHub Actions, GitLab CI oder Bitbucket Pipelines erkennen, wenn Sie Code in Ihr Repository pushen. Sie führen dann eine festgelegte Reihe von Schritten aus: Tests ausführen, Assets bauen und schließlich auf Ihren Server deployen.
Dieser Ansatz ist leistungsfähiger als ein einfacher Git Push. Sie können automatisch Tests ausführen, bevor Code live geht. Sie können Build-Schritte für Frontend-Assets hinzufügen. Sie können in mehrere Umgebungen deployen. Es erfordert aber mehr Einrichtung und Kenntnisse von CI/CD-Konzepten.
Hosting mit integrierter Git-Anbindung
Manche Hosting-Anbieter bauen Git-Deployment direkt in ihre Plattform ein. Sie verknüpfen Ihr GitHub- oder GitLab-Repository und jeder Push auf einen bestimmten Branch löst automatisch ein Deployment aus. Cloudways, Kinsta, Vercel und Netlify sind Beispiele dafür. Das ist die einfachste Option, wenn Ihr Hosting es unterstützt.
Deployment-Tools
Tools wie Deployer für PHP, Capistrano für Ruby oder Envoy für Laravel bieten fortgeschrittene Deployment-Funktionen. Sie definieren Deployment-Aufgaben in Konfigurationsdateien und das Tool führt sie aus. Das ist wertvoll für komplexe Deployments mit mehreren Schritten, für einfache Seiten aber übertrieben.
Git-Deployment auf einem VPS Schritt für Schritt einrichten
Schritt eins: Git auf dem Server installieren
Melden Sie sich per SSH an Ihrem Server an. Installieren Sie Git, falls es noch nicht vorhanden ist. Unter Ubuntu oder Debian tun Sie das mit apt update, gefolgt von apt install git. Unter CentOS oder RHEL verwenden Sie yum install git. Prüfen Sie die Installation mit git version.
Schritt zwei: ein Bare Repository anlegen
Legen Sie ein Verzeichnis für Ihr Git-Repository an, etwa /var/repo/mysite.git. Wechseln Sie in dieses Verzeichnis und initialisieren Sie ein Bare Repository mit git init bare. Ein Bare Repository enthält nur Git-Daten, kein Arbeitsverzeichnis mit Dateien. Es dient ausschließlich dem Empfang von Pushes.
Schritt drei: den Post-Receive-Hook konfigurieren
Die Magie steckt im Post-Receive-Hook. Das ist ein Skript, das Git nach dem Empfang eines Pushes ausführt. Erstellen Sie die Datei hooks/post-receive in Ihrem Bare Repository. Dieses Skript muss den Code in Ihr Website-Verzeichnis auschecken.
Ein einfaches Skript definiert Variablen für Ihr Zielverzeichnis und den Speicherort des Repositorys. Es liest die empfangenen Referenzen und prüft, ob es der richtige Branch ist. Falls ja, checkt es den Code in das Zielverzeichnis aus. Machen Sie das Skript mit chmod plus x ausführbar.
Schritt vier: das Remote zu Ihrem lokalen Repository hinzufügen
In Ihrem lokalen Projekt fügen Sie ein neues Remote hinzu, das auf Ihren Server zeigt. Verwenden Sie git remote add production mit der SSH-Adresse Ihres Repositorys. Sie können dem Remote einen beliebigen Namen geben; production beschreibt gut, wohin der Code geht.
Schritt fünf: deployen
Jetzt können Sie mit einem einfachen Befehl deployen: git push production main. Git pusht Ihre Commits auf den Server, der Post-Receive-Hook läuft und Ihr Code erscheint im Website-Verzeichnis. Jeder weitere Push funktioniert auf dieselbe Weise.
Deployment mit GitHub Actions automatisieren
GitHub Actions bietet eine leistungsfähige Möglichkeit, das Deployment zu automatisieren. Sie erstellen eine Workflow-Datei in Ihrem Repository unter .github/workflows. Diese YAML-Datei legt fest, wann der Workflow läuft und welche Schritte ausgeführt werden.
Ein einfacher Deployment-Workflow wird durch Pushes auf den main-Branch ausgelöst. Der Job läuft auf einem Ubuntu-Runner, checkt den Code aus und verbindet sich per SSH mit Ihrem Server, um einen git pull auszuführen. Die SSH-Zugangsdaten konfigurieren Sie als Secrets in den Einstellungen Ihres GitHub-Repositorys, damit sie sicher sind.
Der Vorteil von GitHub Actions gegenüber einem direkten Git Push ist, dass Sie zusätzliche Schritte hinzufügen können. Führen Sie zuerst Tests aus, um sicherzugehen, dass der Code funktioniert. Bauen Sie Frontend-Assets mit npm oder webpack. Schicken Sie eine Benachrichtigung an Slack, wenn das Deployment gelingt oder fehlschlägt. Die Möglichkeiten sind umfangreich.
Best Practices für sicheres und zuverlässiges Git-Deployment
Halten Sie Zugangsdaten aus Ihrem Repository heraus
Das ist entscheidend und nicht verhandelbar. Passwörter, API-Keys, Datenbank-Zugangsdaten und andere Secrets gehören nicht in Ihr Git-Repository. Selbst wenn Ihr Repository privat ist, ist das ein Risiko. Verwenden Sie Umgebungsvariablen, die auf dem Server konfiguriert sind, oder einen Secrets-Manager. Fügen Sie sensible Dateien Ihrer .gitignore hinzu.
Testen Sie, bevor Sie deployen
Mit CI/CD können Sie automatisch Tests ausführen, bevor Code live geht. Wenn Tests fehlschlagen, wird das Deployment nicht durchgeführt. So fangen Sie Bugs ab, bevor sie die Produktion erreichen. Auch ohne automatisierte Tests ist es sinnvoll, lokal zu testen, bevor Sie pushen.
Verwenden Sie eine Staging-Umgebung
Deployen Sie nicht direkt in die Produktion. Halten Sie eine Staging-Umgebung bereit, die der Produktion so weit wie möglich gleicht. Deployen Sie zuerst dorthin, testen Sie manuell oder automatisiert und deployen Sie erst dann in die Produktion. Das fügt eine zusätzliche Sicherheitsebene hinzu.
Atomare Deployments in Betracht ziehen
Fortgeschrittene Deployment-Setups deployen in ein neues Verzeichnis und schalten dann einen Symlink auf die neue Version um. Wenn etwas schiefgeht, können Sie sofort zur vorherigen Version zurück, indem Sie den Symlink zurücksetzen. Die alte Version bleibt intakt. Tools wie Deployer unterstützen dieses Muster.
Eine Rollback-Strategie haben
Wissen Sie, wie Sie zu einer vorherigen Version zurückkehren, wenn etwas schiefgeht. Mit Git ist das technisch einfach: Sie können einen Commit reverten oder auf einen früheren Stand zurücksetzen. Üben Sie das aber, bevor Sie es in einer Krise brauchen. Kennen Sie die Befehle und wissen Sie, wie sie funktionieren.
Besondere Überlegungen für WordPress und Git
WordPress verlangt beim Git-Deployment besondere Aufmerksamkeit. Die Datei wp-config.php enthält Datenbank-Zugangsdaten und gehört nicht in Ihr Repository. Fügen Sie sie der .gitignore hinzu und verwalten Sie sie separat auf dem Server. Das uploads-Verzeichnis enthält von Benutzern hochgeladene Medien und gehört ebenfalls nicht in Git. Verwenden Sie .gitignore und verwalten Sie Medien separat oder über ein CDN.
Die Datenbank selbst enthält Inhalte und Einstellungen, die nicht über Git laufen. Datenbankmigrationen sind komplexer als das Deployment von Dateien. Ziehen Sie ein Tool wie WP Migrate oder einen Workflow mit Datenbankexporten in Betracht.
Bedrock ist ein moderner WordPress-Stack, der besser mit Git zusammenarbeitet. Er strukturiert WordPress als Abhängigkeit und trennt Konfiguration von Code. Wenn Sie es mit WordPress und Git ernst meinen, lohnt es sich, Bedrock genauer anzusehen.
Häufige Fehler und wie Sie sie vermeiden
Ein häufiger Fehler ist, ohne Tests zu deployen. Es funktioniert lokal, also funktioniert es bestimmt auch in der Produktion, oder? Nein. Unterschiede in der Umgebung, fehlende Abhängigkeiten und abweichende Konfigurationen können Probleme verursachen. Testen Sie immer.
Zugangsdaten zu committen ist ein weiterer Fehler mit ernsten Folgen. Selbst wenn Sie sie später entfernen, bleiben sie in der Git-Historie. Verwenden Sie git-secrets oder vergleichbare Tools, um das versehentliche Committen von Secrets zu verhindern.
Kein Monitoring nach dem Deployment ist ebenfalls riskant. Sie deployen und nehmen an, dass alles funktioniert. Prüfen Sie aber tatsächlich, ob die Seite läuft und ob kritische Funktionen arbeiten. Automatisieren Sie das, wo es möglich ist.
Git-Deployment verändert die Art, wie Sie Websites verwalten. Die anfängliche Einrichtung kostet Zeit, aber die Vorteile bei Geschwindigkeit, Zuverlässigkeit und Nachvollziehbarkeit machen das mehr als wett. Beginnen Sie einfach mit einem simplen Git-Push-Setup und erweitern Sie es auf CI/CD, wenn Ihre Anforderungen wachsen.
Git-Deployment: Checkliste und Best Practices
Ein erfolgreiches Git-Deployment erfordert einen strukturierten Ansatz. Nutzen Sie die folgende Checkliste, damit jedes Git-Deployment reibungslos verläuft.
- Prüfen Sie vor dem Git-Deployment, ob alle Änderungen committet sind
- Führen Sie Tests lokal aus, bevor Sie ein Git-Deployment starten
- Verwenden Sie Feature-Branches und mergen Sie erst nach einem Review in main
- Konfigurieren Sie automatisches Git-Deployment über CI/CD-Pipelines
- Halten Sie bei jedem Git-Deployment eine Rollback-Strategie bereit
- Dokumentieren Sie jedes Git-Deployment in einem Changelog
| Git-Deployment-Methode | Komplexität | Geeignet für |
|---|---|---|
| Manueller git pull | Niedrig | Kleine Projekte |
| Git-Hooks (post-receive) | Mittel | Einzelner Server |
| CI/CD (GitHub Actions) | Mittel bis hoch | Teams und professionelle Projekte |
| Kubernetes + GitOps | Hoch | Enterprise und Microservices |
Ob Sie eine einfache Website auf einem VPS hosten oder eine komplexe Anwendung verwalten: Git-Deployment macht die Verwaltung Ihres Codes übersichtlich und zuverlässig. Kombinieren Sie Git-Deployment mit einer guten Hosting-Umgebung für die besten Ergebnisse.
Wie richten Sie Git-Deployment ein: CI/CD-Pipelines?
Der nächste Schritt nach manuellem Git-Deployment ist die Einrichtung einer automatisierten CI/CD-Pipeline (Continuous Integration/Continuous Deployment). Damit wird Ihr Code automatisch getestet und deployt, sobald Sie Änderungen in Ihr Repository pushen.
GitHub Actions für das Deployment
GitHub Actions ist eine beliebte Wahl für automatisiertes Deployment. Sie definieren Workflows in YAML-Dateien, die bei jedem Push ausgeführt werden. Ein typischer Deployment-Workflow enthält die folgenden Schritte:
- Code aus dem Repository abrufen
- Abhängigkeiten installieren (npm install, composer install)
- Tests ausführen (Unit-Tests, Integrationstests)
- Assets bauen (CSS und JavaScript kompilieren)
- Per SSH oder rsync auf den Produktionsserver deployen
GitLab CI/CD als Alternative
GitLab bietet eine integrierte CI/CD-Lösung, die besonders leistungsfähig ist. Die Pipeline wird in einer Datei .gitlab-ci.yml im Root-Verzeichnis Ihres Repositorys definiert. GitLab unterstützt außerdem Environments, Review Apps und Auto-Deploy auf Kubernetes-Cluster.
Wie vergleichen Sie Git-Deployment-Strategien?
Es gibt verschiedene Strategien für Git-Deployment, jede mit eigenen Vor- und Nachteilen.
| Strategie | Ausfallzeit | Komplexität | Rollback | Geeignet für |
|---|---|---|---|---|
| Direktes Deployment | Kurz | Niedrig | Git revert | Kleine Projekte |
| Blue-Green-Deployment | Keine | Mittel | Sofort (Umschalten) | Produktionsumgebungen |
| Rolling Deployment | Keine | Hoch | Schrittweise | Mehrere Server |
| Canary Deployment | Keine | Hoch | Schnell | Große Anwendungen |
Blue-Green-Deployment erklärt
Beim Blue-Green-Deployment betreiben Sie zwei identische Produktionsumgebungen: "blue" (aktuelle Version) und "green" (neue Version). Sie deployen den neuen Code in die Green-Umgebung, testen sie gründlich und leiten dann den Traffic von Blue auf Green um. Bei Problemen schalten Sie sofort zurück.
Best Practices für Git-Deployment
Damit Ihr Git-Deployment-Prozess zuverlässig und sicher bleibt, befolgen Sie diese Best Practices:
- Verwenden Sie Feature-Branches: Entwickeln Sie neue Funktionen auf separaten Branches und mergen Sie erst in main, wenn alles getestet ist
- Automatisieren Sie Tests: Lassen Sie niemals Code deployen, der nicht alle Tests erfolgreich durchlaufen hat
- Konfiguration außerhalb des Repositorys: Speichern Sie Passwörter, API-Keys und andere sensible Daten in Umgebungsvariablen, nicht in Ihrem Code
- Datenbankmigrationen separat ausführen: Führen Sie Migrationen aus, bevor Sie den neuen Code deployen, um Kompatibilitätsprobleme zu vermeiden
- Monitoring nach dem Deployment: Richten Sie ein Uptime-Monitoring ein, um Probleme gleich nach dem Deployment zu erkennen
- Dokumentieren Sie Ihren Deployment-Prozess: Sorgen Sie dafür, dass jedes Teammitglied den Prozess ausführen kann, nicht nur der Lead Developer
Mit einem gut eingerichteten Git-Deployment-Prozess sparen Sie jede Woche Stunden an manueller Arbeit und minimieren das Fehlerrisiko, wenn Sie Änderungen an Ihrer Website live schalten.
Git-Deployment: häufige Fehler vermeiden
Bei der Einrichtung von Git-Deployment werden regelmäßig dieselben Fehler gemacht, die beim Live-Schalten von Änderungen zu Problemen führen. Kennen Sie diese Fallstricke und vermeiden Sie sie.
Der häufigste Fehler ist das Committen sensibler Informationen in das Repository. Passwörter, API-Schlüssel und Datenbankdaten gehören nicht in Ihre Codebasis. Verwenden Sie eine .gitignore-Datei, um Konfigurationsdateien auszuschließen, und bewahren Sie sensible Daten in Umgebungsvariablen auf. Wenn Sie versehentlich Geheimnisse committet haben, reicht es nicht, sie in einem neuen Commit zu entfernen: Sie stehen noch in der Git-Historie. Verwenden Sie Tools wie git-filter-repo, um die Historie umzuschreiben.
Ein weiterer häufiger Fehler ist, direkt in die Produktion zu deployen, ohne eine Staging-Umgebung zu nutzen. Testen Sie Ihre Änderungen immer zuerst in einer Umgebung, die mit der Produktion identisch ist. So verhindern Sie, dass Bugs, Konflikte oder Konfigurationsprobleme erst auf dem Live-Server entdeckt werden. Automatisieren Sie diesen Prozess, indem Sie Ihre CI/CD-Pipeline so einrichten, dass Änderungen zuerst auf Staging deployt werden.
Vergessen Sie auch nicht, Ihre Deployment-Skripte idempotent zu machen. Das bedeutet, dass das Skript dasselbe Ergebnis liefert, egal wie oft Sie es ausführen. Wenn ein Deployment auf halbem Weg fehlschlägt und Sie es erneut ausführen, darf das keine Probleme verursachen. Verwenden Sie bedingte Prüfungen und Transaktionen in Ihren Migrationsskripten, um das sicherzustellen. Mit guten Migrationspraktiken und automatisierten Tests bauen Sie ein robustes Deployment-System, das Ihrem Team bei jedem Release Vertrauen gibt.
Git-Deployment: Ihre erste Pipeline einrichten
Wenn Sie noch keine Erfahrung mit automatisiertem Git-Deployment haben, beginnen Sie mit einem einfachen Setup, das Sie schrittweise erweitern können. Am einfachsten starten Sie mit einem Post-Receive-Hook auf Ihrem Produktionsserver. Das ist ein Skript, das automatisch ausgeführt wird, wenn Sie Code auf den Server pushen. Das Skript holt den neuesten Code und startet bei Bedarf den Webserver neu.
Einen Schritt weiter geht die Einrichtung eines GitHub-Actions-Workflows. Erstellen Sie in Ihrem Repository eine Datei unter dem Pfad .github/workflows/deploy.yml. Legen Sie darin die Schritte fest, die bei jedem Push auf den main-Branch ausgeführt werden sollen: Code abrufen, Tests ausführen und per SSH deployen. GitHub bietet großzügige kostenlose Minuten für öffentliche und private Repositorys, sodass Sie ohne zusätzliche Kosten starten können. Beginnen Sie einfach und fügen Sie nach und nach weitere Schritte hinzu, wenn Ihr Vertrauen wächst. Eine CI/CD-Pipeline ist nie fertig: Sie entwickelt sich mit Ihrem Projekt weiter und wird immer zuverlässiger, je mehr Tests und Prüfungen Sie dem Prozess hinzufügen.
Git-Deployment: Fazit und nächste Schritte
Mit einem gut eingerichteten Git-Deployment-System heben Sie Ihren Entwicklungs-Workflow auf ein professionelles Niveau. Die Vorteile sind unverkennbar: Jede Änderung ist nachvollziehbar, Zurücksetzen ist einfach und die Zusammenarbeit mehrerer Entwickler verläuft ohne Konflikte. Beginnen Sie einfach mit einem Basis-Workflow, der bei jedem Push auf main automatisch auf Ihren Produktionsserver deployt. Fügen Sie nach und nach weitere Schritte hinzu: automatisierte Tests, Linting, Sicherheitsscans und Benachrichtigungen. Dokumentieren Sie Ihren Deployment-Prozess, damit jedes Teammitglied ihn ausführen und verstehen kann. Investieren Sie in eine Staging-Umgebung, um Änderungen zu testen, bevor sie live gehen. Mit diesen Bausteinen schaffen Sie einen zuverlässigen, wiederholbaren Deployment-Prozess, der Ihnen bei jedem Release Sicherheit gibt und das Risiko menschlicher Fehler minimiert.
Git-Deployment: Best Practices für Teams
Bei der Arbeit mit Git-Deployment im Team gibt es zusätzliche Best Practices, die den Prozess reibungsloser machen. Verwenden Sie Branch Protection Rules, um zu verhindern, dass jemand ohne Code-Review direkt auf main pushen kann. Richten Sie verpflichtende Pull-Request-Reviews ein, sodass mindestens ein Teammitglied jede Änderung freigibt, bevor sie gemergt wird. Verwenden Sie konventionelle Commit-Messages mit einem festen Format, damit die Historie lesbar bleibt und Changelogs automatisch erzeugt werden können. Implementieren Sie automatische Rollbacks, die die vorherige Version wiederherstellen, wenn ein Deployment fehlschlägt oder das Monitoring erkennt, dass die neue Version Fehler verursacht. Halten Sie Ihre Branches kurzlebig: Feature-Branches, die länger als eine Woche bestehen, lassen sich schwer mergen und verursachen Konflikte. Mit diesen Praktiken bauen Sie eine robuste Deployment-Pipeline, der das ganze Team vertraut.
