3D-Cartoon-Entwickler mit Brille gestikuliert an modernem Schreibtisch vor Laptop mit Versionsverzweigungsdiagramm, Codeebenen im Hintergrund.

Versionskontrolle mit Git funktioniert in der WordPress-Entwicklung so, dass alle Änderungen am Code, an Themes und Plugins in einem Repository gespeichert, nachverfolgt und bei Bedarf rückgängig gemacht werden können. Statt Dateien manuell per FTP auf den Server zu übertragen, arbeiten Entwickler in strukturierten Branches und mergen Änderungen erst nach Prüfung in die Produktionsumgebung. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um Git, WordPress-Entwicklung, Workflow und Deployment.

Warum braucht WordPress-Entwicklung überhaupt Versionskontrolle?

WordPress-Entwicklung braucht Versionskontrolle, weil ohne sie jede Codeänderung ein unkontrolliertes Risiko darstellt. Wer direkt auf dem Live-Server editiert, kann einen Fehler nicht einfach rückgängig machen, und bei mehreren Entwicklern überschreibt schnell einer die Arbeit des anderen. Git löst beide Probleme strukturell.

Konkret bringt Versionskontrolle in der WordPress-Entwicklung folgende Vorteile:

  • Vollständige Änderungshistorie: Jeder Commit dokumentiert, wer wann was geändert hat. Fehler lassen sich auf den genauen Zeitpunkt eingrenzen und gezielt rückgängig machen.
  • Paralleles Arbeiten: Mehrere Entwickler können gleichzeitig an verschiedenen Features arbeiten, ohne sich gegenseitig zu blockieren.
  • Sicheres Experimentieren: Neue Funktionen werden in einem separaten Branch entwickelt. Scheitert das Experiment, wird der Branch einfach gelöscht, ohne dass die Produktionsumgebung betroffen ist.
  • Nachvollziehbarkeit für Kunden und Teams: Commit-Nachrichten erklären, warum eine Änderung vorgenommen wurde, nicht nur, was geändert wurde.

Gerade bei WordPress-Projekten mit individuellen Themes, Custom Plugins und regelmäßigen Updates ist Git kein Luxus, sondern professioneller Standard. Wer ohne Versionskontrolle arbeitet, verlässt sich auf manuelle Backups und Glück.

Welche Dateien und Ordner gehören in ein Git-Repository für WordPress?

In ein Git-Repository für WordPress gehören grundsätzlich nur selbst entwickelter Code: das eigene Theme, selbst geschriebene Plugins sowie Konfigurationsdateien. Standardmäßig installierte WordPress-Kerndateien, Drittanbieter-Plugins und der Upload-Ordner werden nicht versioniert, sondern separat verwaltet.

Eine typische .gitignore-Datei für WordPress schließt folgende Bereiche aus:

  • wp-admin/ und wp-includes/ (WordPress-Kern)
  • wp-content/uploads/ (Mediendateien)
  • wp-content/plugins/ (Drittanbieter-Plugins, die über Composer oder manuell installiert werden)
  • wp-config.php (enthält Datenbankzugangsdaten, die niemals ins Repository gehören)
  • .env-Dateien mit Umgebungsvariablen

Was aktiv ins Repository gehört:

  • Das selbst entwickelte Theme unter wp-content/themes/mein-theme/
  • Eigene Plugins unter wp-content/plugins/mein-plugin/
  • Eine wp-config-sample.php oder eine Konfigurationsvorlage ohne echte Zugangsdaten
  • Projektdokumentation und Build-Konfigurationsdateien (z. B. package.json, composer.json)

Diese Trennung hält das Repository schlank, schützt sensible Daten und vermeidet unnötige Konflikte durch automatisch generierte Dateien.

Wie sieht ein typischer Git-Workflow in der WordPress-Entwicklung aus?

Ein typischer Git-Workflow für WordPress folgt dem Prinzip, dass kein Code direkt auf dem Produktionsserver entwickelt wird. Stattdessen gibt es mindestens drei Umgebungen: lokal, Staging und Produktion, die über Git-Branches abgebildet werden.

Der häufig verwendete Gitflow-Ansatz sieht so aus:

  1. Main-Branch: Enthält immer den stabilen, produktionsreifen Code.
  2. Develop-Branch: Integrationsbranch, in dem fertige Features zusammengeführt werden, bevor sie auf Staging getestet werden.
  3. Feature-Branches: Für jede neue Funktion oder jeden Bugfix wird ein eigener Branch angelegt, z. B. feature/neue-kontaktseite.
  4. Pull Request / Merge Request: Bevor ein Feature-Branch in Develop gemergt wird, prüft ein zweiter Entwickler den Code. Fehler werden erkannt, bevor sie in die Produktionsumgebung gelangen.
  5. Release-Branch: Kurz vor einem Deployment wird ein Release-Branch erstellt, um letzte Anpassungen vorzunehmen, ohne den laufenden Entwicklungsprozess zu unterbrechen.

Für kleinere Teams oder Solo-Entwickler reicht oft ein einfacherer Ansatz mit nur zwei Branches: main für die Produktion und develop für die aktive Entwicklung. Wichtig ist, dass der main-Branch immer deploybar bleibt und niemals direkt bearbeitet wird.

Wie wird Code von Git auf den WordPress-Server deployt?

Code wird von Git auf den WordPress-Server deployt, indem entweder ein automatisiertes CI/CD-System (Continuous Integration/Continuous Deployment) oder ein manuelles Git-Pull auf dem Server ausgeführt wird. Beide Methoden ersetzen den fehleranfälligen manuellen FTP-Upload vollständig.

Manuelles Deployment per Git Pull

Die einfachste Methode: Das Repository wird direkt auf dem Server geklont. Bei jedem Deployment verbindet sich der Entwickler per SSH mit dem Server und führt git pull origin main aus. Diese Methode funktioniert zuverlässig für kleine Teams, erfordert aber SSH-Zugang und ein wenig Disziplin im Workflow.

Automatisiertes Deployment per CI/CD

Professionelle Projekte nutzen Tools wie GitHub Actions, GitLab CI oder Bitbucket Pipelines. Sobald Code in den main-Branch gemergt wird, startet automatisch eine Pipeline, die den Code testet, baut und auf den Server überträgt. Das eliminiert menschliche Fehler beim Deployment und sorgt dafür, dass nur geprüfter Code live geht. Für die laufende WordPress-Wartung ist ein solcher automatisierter Prozess besonders wertvoll, weil Updates und Anpassungen ohne manuelle Eingriffe ausgerollt werden können.

Kann Git auch die WordPress-Datenbank versionieren?

Git kann die WordPress-Datenbank nicht direkt versionieren, weil Datenbanken binäre oder dynamische Daten enthalten, die sich für textbasierte Versionskontrolle nicht eignen. Stattdessen werden Datenbank-Dumps als SQL-Dateien exportiert und separat gesichert.

In der Praxis gibt es zwei bewährte Ansätze für die Datenbankverwaltung in WordPress-Projekten:

  • Regelmäßige SQL-Dumps: Die Datenbank wird als .sql-Datei exportiert und entweder manuell oder automatisiert gesichert. Diese Dumps können zwar ins Repository eingecheckt werden, sind aber meist zu groß und verändern sich zu häufig, um sinnvoll versioniert zu werden.
  • WP-CLI und Migrationsskripte: Mit dem WordPress Command Line Interface lassen sich Datenbankänderungen skripten. Strukturelle Änderungen, etwa neue Custom-Post-Types oder Tabellenstrukturen, werden als PHP-Migrationsskripte ins Repository aufgenommen.

Für Mediendateien gilt dasselbe Prinzip: Der uploads/-Ordner gehört nicht ins Git-Repository. Stattdessen werden Mediendateien über Backup-Systeme gesichert. Tägliche automatisierte Backups, wie sie im Rahmen professioneller WordPress-Betreuung üblich sind, decken diesen Bereich zuverlässig ab.

Welche Tools erleichtern den Git-Einsatz in WordPress-Projekten?

Mehrere spezialisierte Tools erleichtern den Git-Einsatz in WordPress-Projekten erheblich, von der lokalen Entwicklungsumgebung bis hin zur Deployment-Pipeline. Die richtige Kombination hängt von der Teamgröße und der Projektkomplexität ab.

Die wichtigsten Tools im Überblick:

  • Local by Flywheel: Eine lokale WordPress-Entwicklungsumgebung, die sich nahtlos mit Git verbindet. Ideal für den Einstieg, weil sie keine manuelle Server-Konfiguration erfordert.
  • GitHub / GitLab / Bitbucket: Remote-Repository-Plattformen, die neben der Codeverwaltung auch Code-Reviews, Issue-Tracking und CI/CD-Pipelines bieten.
  • Composer: Der PHP-Paketmanager ermöglicht es, WordPress-Plugins und -Themes als Abhängigkeiten zu definieren, statt sie direkt ins Repository einzuchecken. Das hält das Repository sauber und Abhängigkeiten nachvollziehbar.
  • WP-CLI: Das Kommandozeilentool für WordPress ermöglicht Datenbankmigrationen, Plugin-Updates und Konfigurationsänderungen per Skript, was sich ideal in automatisierte Deployment-Prozesse integrieren lässt.
  • DeployHQ, Ploi oder Forge: Deployment-Dienste, die Git-Repositories mit Webservern verbinden und automatische Deployments bei jedem Push in einen definierten Branch auslösen.

Wer neu mit Git in WordPress-Projekten beginnt, sollte mit einer grafischen Oberfläche wie GitKraken oder Sourcetree starten. Diese Tools visualisieren Branches, Commits und Merges und senken die Einstiegshürde erheblich, bevor man zur reinen Kommandozeilenarbeit übergeht.

Wie WP-Profi bei professioneller WordPress-Entwicklung hilft

Strukturierte Entwicklungsprozesse wie Git-Workflows sind der Kern unserer Arbeit bei WP-Profi. Wir entwickeln WordPress-Projekte für Unternehmen im DACH-Raum von Anfang an nach professionellen Standards, damit kein Code unkontrolliert auf Produktionsserver gelangt und jede Änderung nachvollziehbar bleibt.

Was wir konkret anbieten:

  • Individuelle WordPress-Entwicklung mit sauberer, versionierter Codebasis
  • Strukturierte Deployment-Prozesse, die FTP-Uploads der Vergangenheit angehören lassen
  • Laufende WordPress-Wartung und -Pflege, inklusive täglicher Backups und wöchentlicher Updates
  • Deutschsprachiger Support, auch an Wochenenden und Feiertagen bei dringenden Problemen
  • Alle Daten werden ausschließlich auf Servern in Deutschland gespeichert und nach der EU-DSGVO behandelt

Ob Sie ein bestehendes WordPress-Projekt auf professionelle Entwicklungsstandards heben oder eine neue Website von Grund auf aufbauen möchten: Kontaktieren Sie uns über unser kostenloses Website-Check-Angebot und erfahren Sie, wie wir Ihr Projekt strukturiert und sicher umsetzen.

Ähnliche Artikel

Dieser Inhalt wurde mithilfe von KI erstellt und kann Fehler enthalten.

Profi-Check für deine Website

Prüfe dein WordPress mit unserem kostenlosen Webseiten-Check und erhalte ausführliche Ergebnisse und Handlungsempfehlungen zur Performance, Sicherheit, Barrierefreiheit und SEO.
Kostenlosen Profi-Check starten