Amikor egyedi témát készítünk WordPress alapú weboldalunkhoz, vagy mások számára fejlesztünk weboldalakat, akkor jól jön, ha van egy verziókezelőnk, amivel nyomon tudjuk követni a változásokat és szükség esetén vissza tudunk állni egy korábbi verzióra. A legelterjedtebb verziókezelő a Git program, ami megtalálható előtelepítve tárhelyeinken.
Mielőtt részletesen belemennénk, hogy miként kell a git programot használni, fontos tisztáznunk, hogy valójában milyen célból szeretnénk verziókezelőt.
Git ≠ backup
Számos remek módja van a biztonsági mentés létrehozásának, viszont a git nem egyike ezeknek. WordPress oldalunk számos olyan elemet tartalmaz, amit nem tanácsos verziókezelőben tárolni, egyrészt mérete, másrészt az adatok szenzitív volta miatt. Ha biztonsági mentést szeretnénk oldalunkról, akkor használjunk egy erre kifejlesztett megoldást!
Ebből az is következik, hogy verziókezelés céljából nem lesz szükségünk a webtárhely minden fájljára és adatára. Több választásunk is van, hogy mit szeretnénk a verziókezelés hatókörébe helyezni attól függően, hogy mi a célunk a verziókezeléssel.
Git a WordPress téma verziókezelésére
Talán egy legegyszerűbb és legkézenfekvőbb eset, amikor egy egyedi témát vagy child témát fejlesztünk, és ezt szeretnénk menedzselni verziókezelő segítségével. Ebben az esetben viszonylag egyszerű dolgunk van, hiszen elegendő csak az adott téma könyvtárában inicializálnunk egy git repozitóriumot és másra nincs is szükségünk a WordPress fájljai közül. Fontos viszont, hogy ellenőrizzük, hogy a téma tárol-e konfigurációs paramétereket az adatbázisban, hiszen ha igen, akkor ez nem fog szerepelni a git repónkban. Ilyenkor ha nem akarunk lemondani a verziókezelésről, akkor az adatbázisban lévő paramétereket rendszeresen exportálnunk kell. Továbbá meg kell győződnünk arról is, hogy ezek a paraméterek mindenhol importálásra kerülnek, például a helyi fejlesztői környezetünkben és az élő szerveren egyaránt. Ennek megoldása már lényegesen nagyobb szaktudást igényel, ha automatizálni szeretnénk a folyamatot.
Git a WordPress állapotának verziókezelésére
Ha nem csak a témát szeretnénk verziókezelés alá vonni, hanem más elemeit is oldalunknak, úgy már sokkal nagyobb kihívás elé nézünk. Kezdjük a gyakorlati problémákkal amikbe ütközhetünk.
Először is meg kell határozni, hogy mi az, amit még szeretnénk kihagyni a verziókezelésből. A bővítményeket mentsük-e, vagy csak bizonyos bővítményeket? A WordPress verziót is mentsük egy az egyben, vagy csak legyen egy változó, ami megmutatja, hogy éppen melyik WordPress verzióval működött legutoljára az oldal. Az automatikus frissítéseket engedélyezzük-e, vagy legyen minden frissítés manuális, hiszen így tarthatjuk kézben azt, hogy a különböző verziókkal tényleg legyen egy-egy mentett állapotunk? Az adatbázisban történő változásokat miként jelezzük, készítsünk-e erről mentést, vagy azt külön tároljuk, és ha igen, akkor milyen gyakran végezzünk rajta mentést?
Ezen túl rengeteg elvi kérdést is fel kell tennünk. Például a wp-config.php-t mentsük-e? Nem javasolt, mivel jelszót tartalmaz, de ha ott végzünk valamilyen változtatást, akkor azt miként vezessük a verziókezelésünkbe? A WordPress kódja már elérhető github.com-on az egy külön repozitórium, és mint olyan nem javasolt sajátunkként kezelni, még akkor sem, ha nyílt forráskódú szoftverről van szó.
Ezeket a kérdéseket nagyjából megválaszolhatjuk akkor, ha sikerült konkrétan leszűkítenünk azt, hogy mi a valódi célunk a verziókezeléssel. Például egy jó cél lehet, hogy könnyen össze tudjunk állítani egy fejlesztői környezetet. Ebben az esetben az előbbiekben felvázolt téma verziókezelése megfelelő lehet, hiszen ennek a verzióira vagyunk kíváncsiak. Ez a rész, amit mi fejlesztünk, ezt ismerjük, és ebben végzünk módosításokat. Az oldal többi része verziókezelés szempontjából nem számít. Ugyanakkor érdemes lehet egy telepítési útmutatót írnunk, hogy a környezet minden fejlesztői eszközön ugyanolyan lehessen.