Ich fasse Mal einen alten Thread an, aber das in in dem Falle ganz passend.
Es gab nämlich (ich glaube hier im Forum) einen Thread, der beschrieb, wie man seine Instanzen mit GIT und FTP immer schön aktuell halten kann. Die hatte ich seinerseits gar nicht verstanden und ausserdem finde ich sie jetzt nicht mehr.
Aber da ich genau das gerade für meine Instanz aufgesetzt habe und neue Teammitglieder gefragt haben, wie das denn gehen soll
Habe ich direkt mitgeschrieben und eine hoffentlich verständliche Anleitung produziert....
Mehrere phpwcms-Installationen aktuell halten
Möglicherweise hast du schon eine oder mehrere Installationen auf verschiedenen Servern laufen. Ggf. erfolgte historische Änderungen kommen später ins Spiel (ab Schritt 5)
Voraussetzung:
Es braucht ein paar Programme:
- Einen FTP Client (den braucht es auch fürs ganz normale Aufsetzen der phpwcms Installation)
- Eine Installation eines Git-Clients (ich nutze sogar zwei: Tortoise Git, als Windows Explorer Erweiterung und Sourcetree). Ersteres liefert gleich auch das Git Kommandozeilen-Tool mit, ein paar Aktionen sind in einem „guten alten Dos-Fenster“ schneller erledigt bzw. hier dokumentiert.
- Ein Programm, dass Dateien und Verzeichnisbäume vergleichen kann (ich nutze gerne Winmerge,
https://winmerge.org/)
Schritt 1: (optional, aber empfehlenswert)
Erstelle einen eigenen Fork des phwpwcms Repository auf Github. Falls du später diesem Klon Änderungen hinzufügst, beachte, dass ein Fork öffentlich zugänglich ist. Dein Fork hat dann eine URL in der Form
https://github.com/<deinbenutzername>/<deinKlonname>
Alternativ checke das Original Repository aus und hoste es auf einer eigenen GIT Instanz.
Theoretisch funktioniert diese Anleitung auch ganz ohne, dass du dein lokales Repository auf einem Server spiegelst. Das rächt sich spätestens bei einem Rechnerwechsel oder wenn mehr als ein Verantwortlicher am System arbeitet.
Schritt 2 Checke das geforkten phpwcms-Version per GIT aus
Starte eine Windows Kommandozeile und prüfe kurz, ob git verfügbar ist. Gebe einfach nur ein:
Wenn ein längerer Text erscheint, ist alles OK. Kommt eine Fehlermeldung, überpfüfe deine GIT-Installation.
Entscheide dich nun für ein Arbeitsverzeichnis auf der lokalen Festplatte. Das ist das Verzeichnis, das später auf Deinen Webserver hochgeladen wird, um die Installation bzw. das Update durchzuführen. Setze das Arbeitsverzeichnis und die URL deines Forks in diese Kommandozeile ein:
Code: Select all
git.exe clone --progress -v "https://github.com/<meinbenutzername>/<meinKlonname>" "C:\<arbeits>\<verzeichnis>"
Git kopiert nun die Dateien aus dem Remote Repository ins lokale Arbeitsverzeichnis.
Schritt 3 Verknüpfung mit dem Original Repository
Der lokalen Arbeitskopie das Das Original-Repo als Upstream hinzufügen
Code: Select all
cd "C:\<arbeits>\<verzeichnis>"
git.exe remote add upstream https://github.com/slackero/phpwcms
Erstelle lokal und im Fork für jede eigenständig zu pflegende Instanz einen eigenen Branch. Wechsle in diesen Branch.
Code: Select all
git branch meinservername
git checkout meinservername
Ein Git Branch ist wie ein Ast an einem Baum, der sich ggf. weiter verzweigt. Jeder Branch enthält einen eigenständigen Stand des gesamten Verzeichnisbaums. Im Gegensatz zu Bäumen kann man zum Glück verschiedene Äste auch wieder zusammenführen oder Änderungen von einem Ast zu einem anderen übertragen.
Möglicherweise möchtest du auch eine Ebene mehr konfigurieren, wenn du mehrere Instanzen hast und einige Anpassungen global waren während andere für die jeweilige Instanz individuell sind. Dann kannst Du die globalen Anpassungen entweder in deinen Master-Branch einpflegen, oder du zweigt vom Master-Branch ab und erzeugst zuerst einen Branch für die globalen Anpassungen und verzweigst erst dann in die Server-Branches.
Schritt 5 Historische Änderungen einpflegen: Vorbereitungen
Falls Du gerade eine neue Installation von phpwcms beginnst, kannst du nun ein paar Kapitel vorspulen. Ansonsten sei der Tipp erlaubt, Schritt 6 und 7 am besten „Häppchenweise“ abzuarbeiten, um zusammengehörige Änderungen zusammen und getrennte Änderungen getrennt zu halten.
Wahrscheinlich hast du in deiner bereits bestehenden Instanz ein paar dateibasierte Anpassungen gemacht, z.B. Templates für Content Parts, Frontend-Renderer, Modul-Anpassungen etc.pp. Es ist Zeit für ein Review und dann werden diese Anpassungen in den Server-Branch übertragen. Kopiere dazu per FTP die gesamte Server-Instanz in ein anderes lokales Verzeichnis als dein lokales Repository im Arbeitsverzeichnis.
Wenn du eigene Anpassungen innerhalb des original phpwcms-Codes vorgenommen hast, kann es hilfreich sein, vorher das Arbeitsverzeichnis auf den gleichen (alten) Versionsstand zu bringen, der noch auf Deinem Server läuft. Dazu kannst du im lokalen Arbeitsverzeichnis Git einfach als „Zeitmaschine“ nutzen. Das geht am bequemsten mit einem der o.g. genannten graphischen Git Clients, wenn du die Historie einblendet und die Version dort mit der rechten Maustaste auswählst. Beim Zeitreisen gibt es eine kleine Warnung, dass ein „detached head“ erzeugt wird. Damit niemanden der Kopf aberissen wird, erzeuge wir dann sofort einen eigenen Zweig für die Anpassungen. (Dann ist auch der Kopf wieder dran).
Code: Select all
git checkout phpwcms-1.8.4
git branch meine-anpassungen
(Von ersten Befehl gibt es mehrere Varianten, ggf. musst du auch eine Commit-ID statt des Tags verwenden.)
Schritt 6 Änderungen finden und ins Arbeitsverzeichnis übernehmen
Wenn du eine schon länger laufende und öfters mal angefasste Instanz hast, kann es jetzt ein wenig lästig werden. Du musst „nur noch“ alle deine (historischen) Anpassungen herausfiltern und in das lokale Repository bringen, ggf. auf deinen globalen bzw. individuellen Server-Branch verteilt. Ein Tool, dass Verzeichnisse und Dateiinhalte vergleichen kann, ist jetzt hilfreich. Ich persönlich nehme gerne „WinMerge“
https://winmerge.org/. Dort werden gleich Arbeits- und Vergleichsverzeichnis ausgewählt und verglichen.
Deine Änderungen pflegst du nun in dein lokales Git-Repository ein.
Achtung:
Die Datei include\config\conf.inc.php wird sich bestimmt als verändert herausstellen. Diese gehört wegen der enthaltenen Passwörter aus Sicherheitsgründen
NICHT ins Remote Repository – du solltest sie an anderer Stelle sichern.
Hinweis:
Die Inhalte aus /content/images sowie /filearchive werden nicht in die Arbeitskopie eingepflegt. Sie enthalten Datei-Inhalt aus Uploads im Backend.
Schritt 7: Committe das Arbeitsverzeichnis
Committe deine Änderungen ins Repository. Es empfiehlt sich auch, sie ins Remote Repository zu pushen, dann sind die Daten direkt auch gesichert. An der Stelle sei nochmals erwähnt, dass Dein Fork auf Github öffentlich zugänglich ist.
Code: Select all
git commit -m "Images-Contentpart-Template mit Rahmen ums Bild"
git push
(der Teil mit dem -m ist der Commit-Kommentar)
Nun sind deine historischen Änderungen im Arbeitsverzeichnis auf den damaligen Stand des phpwcms abgebildet. Das Schlimmste ist nun geschafft.
Schritt 8: phpwcms Version aktualisieren
Wechsle per git in deinen Server-Branch (s. Schritt 4)
Dieser enthält natürlich noch nicht die Anpassungen; dazu wird der Zweig meine-anpassungen mit dem Zweig meinservername zusammengeführt:
Das wird häufig einfach glatt gehen, aber je älter die alte Version war, desto häufiger kann es zu sog. Merge-Konflikten kommen. Dann wurden gleiche Dateien in beiden zu vereinigenden Ästen so bearbeitet, dass das zusammenführen nicht sicher geschehen kann. Oder es wurden Dateien aus den Beispielverzeichnissen verschoben und produktiv geholt.
Wieder lohnen sich die graphischen Git-Tools, denn es führt kein Weg am manuellen lösen der Konflikte vorbei.
Sind alle Merge-Konflikte gelöst, kannst du den Merge committen. Der kommentar beim Merge ist ein besonderer, dehr arbeite auf der Kommandozeile ohne das -m und bestätige den Kommentar in einem Editor-Fenster
+ Tastenkürzel shift-ZZ im folgenden Editor-Fenster
Schritt 9: Hochladen des Arbeitsverzeichnisses auf den Server
Jetzt können die Dateien vom Arbeitsverzeichnis wieder auf den Server übertragen werden, z.B. mit dem FTP-Client. Dabei werden die Dateien auf dem Webserver überschreiben. Einzige Ausnahme: das Verzeichnis mit dem Namen .git wird nicht hochgeladen.
Vergiss nicht, die Dateirechte entsprechend der Installationsanleitung zu prüfen.
Schritt 10: Setup/Db-Upgrade
Führe einmal das Setup aus, dann das setup-Verzeichnis vom Server löschen.
Schritt 11: aktuell bleiben
„Natürlich“ kommt wenige Tage nach dem Update ein neues Release, das soll auch eingepflegt werden. Nach der Vorarbeit wird es jetzt aber einfach.
- Hole die Änderungen von Olivers zentralem Repository ins lokale Arbeitsverzeichnis.
- Merge die Änderungen in deinen Server Zweig
- Ggf. Konflikt-Behebung (sollte nur noch selten nötig sein)
- Committe
(shift ZZ)
- Und Übertragung per FTP -> Schritt 9
