Update zu Git vs. WordPress: Deployment mit Revisr

Bisheriges Vorgehen und Umschwenken auf Revisr

Vor einiger Zeit habe ich im Artikel PHP- bzw. WordPress-Projekte mit Git verwalten und deployen beschrieben, wie ich meine Webprojekte in Git pflege und auf meinen produktiven Webservern deploye. Scheinbar hat mein Hoster etwas geändert und plötzlich lief dieses Vorgehen nicht mehr sauber. Es kam häufig zu Timeouts beim Zugriff auf das Git-Repository. Aus diesem Grund habe ich dem WordPress-Plugin Revisr eine Chance gegeben und mittlerweile viele meiner Projekte umgestellt.

Revisr ist ein WordPress-Plugin, aber auch ein Git-Client. Voraussetzung ist, dass der Kommandozeilenbefehl git auf dem Webserver verfügbar ist (siehe Anmerkungen hier). Revisr ruft intern diesen Befehl auf, bietet aber nach außen hin eine komfortable Benutzeroberfläche. Die Arbeitsweise von Git (commit/push/pull) sollte aber dem Anwender bekannt sein. Wer damit noch nicht vertraut ist, dem kann ich das interaktive Tutorial Try Git empfehlen.

Einen guten Einstieg in Revisr bietet die offizielle Dokumentation unter Getting Started. Ich werde im folgenden erklären, wie ich diese Webseite (www.bjoerne.com) auf die Nutzung von Revisr umgestellt habe.

Meine Webseite existiert bereits

In meinem Fall existiert die Seite bereits. Sie ist auch schon in einem lokalen Git-Repository sowie in einem Remote-Repository auf Bitbucket.

Revisr habe ich allerdings noch nicht installiert. Das tue ich nun ganz konventionell. Ich lade mir das Plugin von der Seite https://wordpress.org/plugins/revisr/ herunter und lade es per FTP auf meinen Webspace.

Das Verzeichnis mit meiner Webseite auf meinem Webspace ist kein Git-Repository. Damit es ein Repository wird, benötige ich den Ordner .git.  Leider habe ich aber in meinem günstigen Hosting-Paket keinen SSH-Zugang. Ich muss den .git Ordner zunächst auf meinem Computer erstellen und per FTP hochladen.

Ich kann allerdings nicht den .git-Ordner meines lokalen Webprojektverzeichnisses verwenden. Das führt später zu einem Fehler (bad index file sha1 signature). Stattdessen erstelle ich den .git-Ordner auf meinem Computer in einem temporären Verzeichnis neu. Das tue ich mit folgendem Kommandozeilenbefehl:

git clone -n https://bjoerne@bitbucket.org/bjoernecom/bjoerne.git

Der -n Parameter bedeutet, dass nur der .git-Ordner erstellt wird, die Daten aber nicht heruntergeladen werden.

Bevor ich den .git-Ordner hochlade, passe ich die Datei .git/config geringfügig an. Das hat wieder mit meinem Hoster zutun. Da ich mich von meinem Webspace bei Bitbucket nicht per SSH-Schlüssel (das wäre der empfohlene Weg) authentifizieren kann, verwende ich eine Datei .netrc im Benutzerverzeichnis meines Webspace (siehe Anmerkungen hier). Das bedingt, dass ich meinen Benutzernamen aus der Repository-URL entfernen muss. Aus

[remote "origin"]
 url = https://bjoerne@bitbucket.org/bjoernecom/bjoerne.git
 fetch = +refs/heads/*:refs/remotes/origin/*

wird (also ohne bjoerne@ vor der Adresse):

[remote "origin"]
 url = https://bitbucket.org/bjoernecom/bjoerne.git
 fetch = +refs/heads/*:refs/remotes/origin/*

Jetzt kann ich den Ordner hochladen. Um den Zugriff auf die Git-Dateien von außen zu schützen, ist folgender Eintrag in der .htaccess-Datei notwendig:

RedirectMatch 404 /.git

Mein Repository ist eingerichtet, ich kann Revisr aktiveren und das Revisr-Dashboard aufrufen.

Einrichten einer neuen Seite

Falls die Webseite noch nicht besteht oder aber besteht ohne Anbindung an git, ist es nicht ganz so einfach. In solchen Fällen installiere ich mir als Hilfsmittel eine PHP Shell. Ich richte die Shell ein und klone dann per Kommando in ein temporäres Verzeichnis die Webseite. Das klonen an den finalen Ort wäre nur möglich, falls der entsprechende Ordner leer ist.

Per FTP verschiebe ich dann entweder

  • den .git Ordner in den Root-Ordner der Webseite, falls diese bereits besteht
  • den gesamten Code falls, die Webseite frisch aufgebaut wird.

Anschließend sollte Revisr die Anbindung an Git übernehmen und die PHP Shell ist nicht mehr notwendig.

Erste Schritte mit Revisr

Pull

Zunächst drücke ich auf dem Dashboard den Button Pull auf der rechten Seite. Damit kann ich sicherstellen, dass alles korrekt eingerichtet ist.

revisr_quick_actions

Es erscheint ein Popup mit einer Warnmeldung.

revisr_warnung_uncommited_changes

Diese Meldung klingt recht scharf. Ich habe sogar uncommitted changes, nämlich das Revisr-Plugin, das ich per FTP hochgeladen habe und das noch nicht im Repo ist. Die Meldung klingt so, als würden durch Klicken auf OK Daten gelöscht. Das stimmt aber nicht! In welchen Fällen hier Gefahr besteht kann ich nicht genau sagen, ich vermute mal, primär wenn sich dieselben Dateien lokal und remote geändert haben.

Nach Klick auf OK erscheint die freundliche Meldung The local repository is already up-to-date with the remote repository.

Commit

Hinweis: Es besteht die Möglichkeit, mit revisr nur zu Lesen und jegliche Änderungen an der Codebasis auf dem eigenen Computer durchzuführen. Eventuell gibt man dann Revisr auch nur Leseberechtigung auf das Remote-Repository. Die folgenden beiden Schritte sehen vor,  mit Revisr auch zu Schreiben. Diese wären bei einem Read-Only-Vorgehen nicht relevant.

Mit der Meldung There are currently 1 untracked files on branch master. Commit your changes to save them macht mich Revisr darauf aufmerksam, dass auf meinem Webspace Änderungen bestehen, die noch nicht in Git versioniert sind. Durch Klick auf commit gelange ich zu folgender Maske:

revisr_commit

Unter Staged Files sind die Änderungen aufgelistet. Es handelt sich wie erwähnt um das Revisr-Plugin selbst. In das Textfeld oben schreibe die Commit-Message Add revisr plugin. Sprechende Bezeichnungen helfen dabei, sich später in der Historie zurechtzufinden.

Durch Klick auf Commit Changes auf der rechten Seite schließe ich den Schritt ab.

Push

Zurück auf dem Dashboard wird mir durch eine (1) auf dem Push-Button rechts dargestellt, dass noch ein Schritt fehlt: Das Pushen.

revisr_quick_actions_push

Durch Klick auf den Button und Bestätigen des Dialogs schließe ich auch diesen Schritt ab. Bei diesem Schritt ist wichtig, dass eine Schreibberechtigung auf das Remote-Repository besteht.

Pull again

Normalerweise ändere ich Code meiner Webprojekte zunächst lokal. So kann ich lokal zunächst die Änderungen testen, bevor ich meinen Server aktualisiere. Das schließt auch Updates von WordPress oder WordPress-Plugins ein.

Aktuell liegt so ein Update an. Ich führe es lokal durch. Lokal arbeite ich mit git auf der Kommandozeile. Es ist aber auch denkbar, lokal mit Revisr zu arbeiten. Eine weitere Alternative für Windows und Mac ist der grafische Git-Client SourceTree.

Nachdem ich lokal comitted und gepusht habe, wechsle ich wieder auf das Dashboard von Revisr auf meinem Webserver. Auch hier hilft Revisr mir und stellt das ausstehende Pull optisch durch eine (1) dar:

revisr_quick_actions_pull

Durch Klick auf den Button ist alles wieder aktuell und mein Webspace ist synchron mit meiner lokalen Arbeitsumgebung.

 

bjoerne_com_bjoern_weinbrenner_softwareentwickler_icon_leistungen_02

Lust auf mehr? Als Experte für WordPress und individuelle WordPress-Entwicklung kann ich Sie in Ihren Projekten unterstützen. Melden Sie sich gerne bei mir.

2017-01-28T14:21:55+00:00 23.03.2015|Tags: , , |5 Comments

5 Kommentare

  1. Johannes 3. Mai 2015 um 13:24 Uhr- Antworten

    Sehr schöner Überblick über Revisr, danke für den Tip! Mein eigener Workflow mit SourceTree und Bitbucket läuft soweit rund, deswegen werde ich nicht gleich umsteigen. Aber ich behalte das für später im Blick. Das erste Einrichten klingt mit Revisr jedenfalls schön einfach. Allerdings habe ich im Moment eh das Gefühl, dass ich mehr Updates einspiele als tatsächlich mal etwas zu veröffentlichen. 😉

    • Björn Weinbrenner 3. Mai 2015 um 13:41 Uhr- Antworten

      Hallo Johannes!

      Vielen Dank! Mit SourceTree verweist du auf die lokale Verwendung von Git, oder? Lokal nutze ich nämlich Revisr auch nicht, sondern die Kommandozeile. Revisr setze ich nur im produktiven WordPress-System ein.

      Viele Grüße
      Björn

  2. Alex 23. Mai 2015 um 19:15 Uhr- Antworten

    Hallo Björn,

    schöner Artikel. Ich arbeite mich auch gerade in Git ein und hab da nochmal eine Frage. Ist es möglich, das Remote-Repository auch woanders zu haben ausser Bitbucket? Angenommen ich will Bitbucket nicht nutzen, wäre es auch denkbar das Remote-Repository auf dem gleichen Server zu haben und dann in das Produktivverzeichnis zu deployen oder macht das keinen Sinn?

    • Björn Weinbrenner 23. Mai 2015 um 21:57 Uhr- Antworten

      Hallo!

      Das ist möglich. Aber der Server muss das unterstützen und man hat dann den Installations- und Wartungsaufwand. Ich würde mich da nur heranwagen, wenn das zwingend notwendig ist. Für meine Projekte habe ich volles Vertrauen in Bitbucket.

      Viele Grüße
      Björn

      • Alex 23. Mai 2015 um 23:32 Uhr- Antworten

        Vielen Dank für die Antwort.

Hinterlassen Sie einen Kommentar